I am trying to use cmake to generate Makefile for a MPI program. The issue I have is that I only have mpicc installed (working correctly) the mpicxx is in the PATH but is from an other installation (there are multiple MPIs installed on my system). I don't want to use mpicxx but only mpicc (and the include files and libraries of mpicc).
Bellow is a somewhat hardcoded effort and it works
cmake_minimum_required(VERSION 2.8)
PROJECT(mympihello)
ADD_EXECUTABLE(hellompi hellompi.c)
SET(CMAKE_C_COMPILER mpicc)
target_link_libraries(hellompi /export/home2/SEECS/bibrak/work/programs/installs/mpich3/include)
Following is the generic way (as far as I know) and I want to use this approach but forcing not to use mpicxx (not finding it, discarding mpicxx)
cmake_minimum_required(VERSION 2.8)
PROJECT(mympihello)
ADD_EXECUTABLE(hellompi hellompi.c)
# Require MPI for this project:
find_package(MPI REQUIRED)
set(CMAKE_CXX_COMPILE_FLAGS ${CMAKE_CXX_COMPILE_FLAGS} ${MPI_COMPILE_FLAGS})
set(CMAKE_CXX_LINK_FLAGS ${CMAKE_CXX_LINK_FLAGS} ${MPI_LINK_FLAGS})
include_directories(MPI_INCLUDE_PATH)
target_link_libraries(hellompi ${MPI_LIBRARIES})
Furthermore, it will be helpful to point me towards how to generate .so (shared library) for such programs that use MPI.
Thanks
Some how I managed to do it. Here is my solution to generating .so (shared library) using cmake but only using mpicc not mpicxx
cmake_minimum_required(VERSION 2.8)
project(projectname C)
SET( SOURCE_FILES
sourcefile1.c
sourcefile2.c
sourcefile3.c
)
ADD_LIBRARY(projectname SHARED ${SOURCE_FILES})
find_package(MPI)
if(MPI_FOUND)
set(CMAKE_C_COMPILE_FLAGS ${CMAKE_C_COMPILE_FLAGS} ${MPI_C_COMPILE_FLAGS})
set(CMAKE_C_LINK_FLAGS ${CMAKE_C_LINK_FLAGS} ${MPI_C_LINK_FLAGS})
include_directories(${MPI_C_INCLUDE_PATH})
endif(MPI_FOUND)
target_link_libraries(projectname ${MPI_C_LIBRARIES})
This generates a Makefile that creates projectname.so shared library.
Related
I'm trying to include SFML as a dependency in my CMake project, and it compiles SFML fine, but I can't figure out how to link it.
Here's my CMakeLists.txt, with annotated comments:
cmake_minimum_required(VERSION 3.9.1)
set(CMAKE_LEGACY_CYGWIN_WIN32 1)
set (CMAKE_CXX_STANDARD 11) # Set C++11
project(CHIP8)
set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # static library
set(CMAKE_LIBRARY_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/lib) # dynamic library
set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin) # executables
set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}/modules" ${CMAKE_MODULE_PATH})
# Include SFML
add_subdirectory(${CMAKE_SOURCE_DIR}/dep/SFML)
include_directories(${CMAKE_SOURCE_DIR}/dep/SFML/include)
#Include where to find headers
include_directories(./src)
include_directories(./src/headers)
# Do a GLOB search, and add them to executable
set(EXECUTABLE_NAME "CHIP8")
file(GLOB SRC_FILES
"src/headers/*.h"
"src/*.cpp"
)
add_executable(${EXECUTABLE_NAME} ${SRC_FILES})
target_link_libraries(${EXECUTABLE_NAME} SFML) #Here is where the problem lies!
As you can see, I'm adding the subdirectory ./dep/SFML so it compiles with its own CMakeLists. Including the headers too on the next line, which VSCode picks up.
However, I'm having trouble on the last line: target_link_libraries. It can't find sfml SFML or SFML2. Therefore, I'm not sure how to link it.
Anyone have any idea?
Thanks.
SFML is not a single library, but a set of libraries, each of which corresponds to some component. For component named
<component-name>
the library target is named
sfml-<component-name>
When use SFML in your code, you should know which SFML component(s) you use (see SFML docs/tutorials), and link with corresponded libraries:
# Assuming you use "graphics" and "system" SFML components
target_link_libraries(<your-executable> sfml-graphics sfml-system)
Note, that such targets' naming is not officially documented, so it can be changed in the future.
Preferred way for link with SFML is to install it before (or during) configuring your project, and use
find_package(SFML REQUIRED COMPONENTS graphics system)
include_directories(${SFML_INCLUDE_DIR})
target_link_libraries(<your-executable> ${SFML_LIBRARIES})
[Shamelessly cross-posted from the CMake help list]
I'm trying to create binaries as statically as possible. The fortran code I've got has got X11 and quadmath as dependencies, and I've come across a number of issues (maybe each of these issues should be in a different question?):
My variables are currently
set(CMAKE_LIBRARY_PATH /usr/X11/lib /usr/X11/include/X11 ${CMAKE_LIBRARY_PATH})
find_package(X11 REQUIRED)
find_library(X11 NAMES X11.a PATHS /usr/X11/include/X11/ /usr/X11/lib)
find_library(X11_Xaw_LIB NAMES Xaw Xaw /usr/X11/include/X11/ /usr/X11/lib ${X11_LIB_SEARCH_PATH})
find_library(Xaw Xaw7 PATHS ${X11_LIB_SEARCH_PATH})
set(CMAKE_LIBRARY_PATH /usr/lib/gcc/x86_64-linux-gnu/4.7 /usr/lib/gcc/x86_64-linux-gnu/4.7/x32 /usr/lib/gcc/x86_64-linux-gnu/4.7/32 ${CMAKE_LIBRARY_PATH})
find_library(quadmath NAMES quadmath.a)
set(BUILD_SHARED_LIBS ON)
set(CMAKE_FIND_LIBRARY_SUFFIXES .a ${CMAKE_FIND_LIBRARY_SUFFIXES})
set(LINK_SEARCH_START_STATIC TRUE)
set(LINK_SEARCH_END_STATIC TRUE)
set(SHARED_LIBS OFF)
set(STATIC_LIBS ON)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
Using these, CMake attempts to build every program statically (as expected) - however, it fails because I don't have Xaw.a - I can't find out whether this actually should exist. I have installed the latest libxaw7-dev which I was expecting to fix it. One option would be to compile the X11 libraries myself, but I don't really want to do that...
if I comment out only set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static"), then CMake compiles everything, but uses shared libraries for every program, even though I specify the location of .a X11 libraries in my find_library() calls. I was expecting CMake to use the .a files where it could and then only use shared libraries - is there a way to force this behaviour?
does anyone know yet of a fix for the bug described here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46539; whereby gfortran seemingly can't statically link libquadmath? I tried the fix using gcc but I can't get CMake to recognise the libgfortran flag:
cmake -DCMAKE_Fortran_COMPILER=gcc -DCMAKE_Fortran_FLAGS=-gfortran
results in
-- The Fortran compiler identification is unknown
-- Check for working Fortran compiler: /usr/bin/gcc
-- Check for working Fortran compiler: /usr/bin/gcc -- broken
CMake Error at /usr/share/cmake-2.8/Modules/CMakeTestFortranCompiler.cmake:54 (message):
The Fortran compiler "/usr/bin/gcc" is not able to compile a simple test program.
However, as you might have noticed, I set the location of the libquadmath.a; when I build a program which doesn't use X11 but does use quadmath when I use
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static")
then the program does compile successfully (running ldd reports 'not a dynamic executable') - does this mean that the bug has been fixed, or does it only work because I set the location in CMake?
I was having a similar problem. Turns out that cmake was implicitly linking against libgfortran and libquadmath. To fix this I put the following in my top level CMakeLists.txt:
unset(CMAKE_Fortran_IMPLICIT_LINK_LIBRARIES)
I could then explicitly link again the libraries using:
SET_TARGET_PROPERTIES(main_f PROPERTIES LINKER_LANGUAGE "C"
LINK_FLAGS
"/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libgfortran.a
/usr/local/Cellar/gcc/7.1.0/lib/gcc/7/libquadmath.a -lm -lgcc"
)
The static version of libgfortran is necessary because the shared library also depends on libquadmath. The added "-lm" and "-lgcc" bring in the system dynamic versions of these libraries. On a mac system, you would want to use the full path to your libm.a as well.
I guess your questions are not that much related, I don't know the answer for all of them.
For your static linking problems, since you're using GCC, you can pass multiple -static and -dynamic flags to it:
set(CMAKE_EXE_LINKER_FLAGS "-static ${STATIC_LIBS} -dynamic ${EVERYTHING ELSE} -static ${MORE_STATIC_LIBS}")
I don't know why Xaw.a isn't available on your system, probably because the package maintainer of your Linux distribution didn't really make them available.
Also, compiling everything static might make things not compatible between all distros out there and you cripple the ability for others to use improved, up-to-date libraries with your program, it might not be what you want.
If you intend to make a self-contained package of your program, it might be better just to include the shared libraries you used together, like Dropbox and many other proprietary applications do (Humble Bundle games are other example).
I've searched and found out that a lot of people have the same problem, but no solution exists.
I'm using CMake to generate Makefiles for MinGW and when compiling I'm getting an error:
CMakeFiles\boosttest.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x5e): undefined reference to `_imp___ZN5boost6thread4joinEv'
CMakeFiles\boosttest.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x71): undefined reference to `_imp___ZN5boost6threadD1Ev'
CMakeFiles\boosttest.dir/objects.a(main.cpp.obj):main.cpp:(.text+0x88): undefined reference to `_imp___ZN5boost6threadD1Ev'
This seems to be a linking problem, I get it. My CMake configuration is:
project(boosttest)
cmake_minimum_required(VERSION 2.6)
include_directories(${boosttest_SOURCE_DIR}/include c:/boost_1_48_0/)
link_directories(c:/boost_1_48_0/lib)
file(GLOB_RECURSE cppFiles src/*.cpp)
add_executable(boosttest ${cppFiles})
target_link_libraries(boosttest libboost_thread-mgw46-mt-1_48.a)
First I tried using find_package(Boost COMPONENTS thread) and it was working the same way, so I thought to try to do this manually and I still get the same error.
Any insights on this?
I've compiled it for mingw using bjam and as a static link. Also tried doing:
add_library(imp_libboost_thread STATIC IMPORTED)
set_property(TARGET imp_libboost_thread PROPERTY IMPORTED_LOCATION c:/boost_1_48_0/lib/libboost_thread-mgw46-mt-1_48.a)
target_link_libraries(boosttest imp_libboost_thread)
And I still get the same error messages.
For mingw32 you may add definition BOOST_THREAD_USE_LIB. And linking with boost::thread will work. Also you may need Threads package (but i'm not sure, may be it needs only for *nix platforms).
Here is part of my CMakeLists. I copied it from project, which uses boost::thread, and compiles under mingw-gcc (and other compilers):
set(Boost_USE_STATIC_LIBS ON)
set(Boost_USE_MULTITHREADED ON)
set(Boost_ADDITIONAL_VERSIONS "1.44" "1.44.0")
find_package(Boost COMPONENTS thread date_time program_options filesystem system REQUIRED)
include_directories(${Boost_INCLUDE_DIRS})
find_package(Threads REQUIRED)
#...
if (WIN32 AND __COMPILER_GNU)
# mingw-gcc fails to link boost::thread
add_definitions(-DBOOST_THREAD_USE_LIB)
endif (WIN32 AND __COMPILER_GNU)
#...
target_link_libraries(my_exe
${CMAKE_THREAD_LIBS_INIT}
#...
${Boost_LIBRARIES}
)
In my opinion, this question is similar to this question and this one. My best guess would be that you need the same resolution as in my answer to the first question.
I would strongly recommend the use of find_package (Boost ) and take care with the auto-linking:
project(boosttest)
cmake_minimum_required(VERSION 2.6)
# Play with the following defines
# Disable auto-linking.
add_definition( -DBOOST_ALL_NO_LIB )
# In case of a Shared Boost install (dlls), you should then enable this
# add_definitions( -DBOOST_ALL_DYN_LINK )
# Explicitly tell find-package to search for Static Boost libs (if needed)
set( Boost_USE_STATIC_LIBS ON )
find_package( Boost REQUIRED COMPONENTS thread )
include_directories( ${Boost_INCLUDE_DIRS} )
file(GLOB_RECURSE cppFiles src/*.cpp)
add_executable(boosttest ${cppFiles})
target_link_libraries(boosttest ${Boost_LIBRARIES} )
I'm trying to use cmake (on Linux with GNU make and g++) to build a project with two sub-directories: MyLib and MyApp. MyLib contains source for a static library; MyApp needs to link against that library. I'm trying to build on Linux with generated makefiles using the following CMakeLists.txt:
cmake_minimum_required (VERSION 2.6)
project (MyProj)
include_directories (MyLib)
file(GLOB MyLibSrc MyLib/*.cpp)
add_library(MyLibrary STATIC ${MyLibSrc})
file(GLOB MyAppSrc MyApp/*.cpp)
add_executable(MyApplication ${MyAppSrc})
target_link_libraries(MyApplication MyLibrary)
This 'almost' works. It fails at link time because while it generates libMyLibrary.a - it is in the root. When I add:
link_directories(${MyProj_BINARY_DIR})
it makes no difference.
I've got a few (inter-linked) questions:
What's the best way to coerce cmake into building my library and executable into a 'staging directory' — say MyStage — to keep targets separate from source?
How do I convince cmake to link the application against the library?
If I wanted to build a debug and a release version, what's the best way to extend my cmake scripts to do this — making sure that the debug application links against the debug library and the release application against the release library?
I'm a relative newcomer to cmake. I've read what I can find on the web, but find myself struggling to get my library to link with my executable. This sort of a configuration, to my mind, should be quite common. An example from which to crib would be very helpful, but I've not found one.
Well, it is better to read this example and do exactly as suggested.
cmake_minimum_required (VERSION 2.6)
project (MyProj CXX)
add_subdirectory(MyLib)
add_subdirectory(MyApp)
Then for each subdirectory specified, CMakeLists.txt files are created
MyLib\CMakeLists.txt
file(GLOB SRC_FILES *.cpp)
add_library(MyLib ${SRC_FILES})
MyApp\CMakeLists.txt
file(GLOB SRC_FILES *.cpp)
add_executable(MyApp ${SRC_FILES})
target_link_libraries(MyApp MyLib)
Use "out of the source build". Make a directory used only for build and while in it, call
cmake <path to the sources, it may be relative>
Either use
link_directories(${MyProj_BINARY_DIR}/MyLib)
or make CMakeLists.txt in each subdirectory - that would be better for project larger than very small.
This is a bit tricky, check out CMAKE_BUILD_TYPE in the docs (you can set it and/or "if" by it). You can also set it from command line:
cmake -DCMAKE_BUILD_TYPE=Debug
I've discovered the 'optimal' solution to (1)... so, thought I should post it here:
SET(CMAKE_ARCHIVE_OUTPUT_DIRECTORY MyStage)
SET(CMAKE_RUNTIME_OUTPUT_DIRECTORY MyStage)
The thing that confused me previously is that static libraries are not considered a LIBRARY by Cmake - they're considered to be ARCHIVEs.
Do not add libraries and executables in the root Cmakelists.txt. Add these libraries and executables in Cmakelists.txt of subdirectories.
I know there is something like find_package(Threads) but it doesn't seem to make a difference (at least by itself). For now I'm using SET(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-pthread"), but it doesn't look like a correct solution to me.
The Threads module in the latest versions (>= 3.1) of CMake generates the Threads::Threads imported target. Linking your target against Threads::Threads adds all the necessary compilation and linking flags. It can be done like this:
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
set(THREADS_PREFER_PTHREAD_FLAG TRUE)
find_package(Threads REQUIRED)
add_executable(test test.cpp)
target_link_libraries(test Threads::Threads)
Use of the imported target is highly recommended for new code, according to the CMake docs
find_package( Threads ) calls a CMake module that first, searches the file system for the appropriate threads package for this platform, and then sets the CMAKE_THREAD_LIBS_INIT variable (and some other variables as well). It does not tell CMake to link any executables against whatever threads library it finds. You tell CMake to link you executable against the "Threads" library with the target_link_libraries() command. So, for example lets say your program is called test. To link it against threads you need to:
find_package( Threads )
add_executable( test test.cpp )
target_link_libraries( test ${CMAKE_THREAD_LIBS_INIT} )
How about the following:
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
find_package(Threads REQUIRED)
if(CMAKE_USE_PTHREADS_INIT)
set(CMAKE_C_FLAGS ${CMAKE_C_FLAGS} "-pthread")
elseif(...)
...
endif()
add_executable( test test.cpp )
target_link_libraries( test ${CMAKE_THREAD_LIBS_INIT} )
If I explicitly specify the default entry point and the library to use, it compiles without problems. The default entry point here is to specify the version in cmake.
cmake_minimum_required(...), target_link_libraries(...)
Below is an example.
# important
cmake_minimum_required(VERSION 2.8)
project(main)
# set c++ version & etc...
set(CMAKE_CXX_STANDARD 14)
set(CMAKE_CXX_STANDARD_REQUIRED ON)
# important
find_package( Threads )
add_executable(main main.cpp)
# important
target_link_libraries(main ${CMAKE_THREAD_LIBS_INIT})