I am currently porting my automake into CMAKE. I am trying to find what's equivalent of:
myprogram_LDFLAGS = \
-lcurl \
-ldl \
-lresolv \
-Wl,-rpath,'/approot/services/lib'
What is the corresponding command in cmake to set my rpath?
set(CMAKE_INSTALL_RPATH "/approot/services/lib")
The above command seems to be related to the install time. Whereas, LDFLAGS are linker related.
This worked for me:
set_target_properties(${TARGET} PROPERTIES LINK_FLAGS "-Wl,-rpath,'/approot/services/lib'")
Related
I am trying to build freetype and harfbuzz. The latter depends on the former. Freetype builds with CMake, which I configured to install it in /opt/ossia-sdk.
I tried this as mentioned in Meson: how to make find_library() works with an unusual path? :
export LIBRARY_PATH=/opt/ossia-sdk/freetype
# also tried:
# export LIBRARY_PATH=/opt/ossia-sdk/freetype/lib
meson build -Dbuildtype=release -Ddefault_library=static -Dglib=disabled -Dgobject=disabled -Dicu=disabled -Ddocs=disabled -Dprefix=/opt/ossia-sdk/harfbuzz
Yet it still gets my system freetype, which I do not want.
meson-log.txt has the following:
libraries: =/opt/ossia-sdk/freetype/x86_64-pc-linux-gnu/11.1.0/:/opt/ossia-sdk/freetype/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/:/lib/x86_64-pc-linux-gnu/11.1.0/:/lib/../lib/:/usr/lib/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/../lib/:/opt/ossia-sdk/freetype/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
Build lines look like:
Command line: c++ -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/sysprof-4 /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/testfile.cpp -o /home/jcelerier/ossia/sdk/Linux/harfbuzz/build/meson-private/tmps978npqc/output.exe -pthread -O3 -march=x86-64 -mtune=generic -D_FILE_OFFSET_BITS=64 -O0 -fpermissive -std=c++11 -fno-rtti -Wl,--start-group /usr/lib/libfreetype.so -Wl,--end-group
Any solution must not patch Freetype or harfbuzz's build scripts, I can only call them.
I use CMake for a project of mine involving CUDA. Recently I have had to turn on "separable compilation" of the some of my CUDA code:
set(CUDA_SEPARABLE_COMPILATION ON)
but then, building started to fail. As an example, the following would happen:
/usr/local/cuda/bin/nvcc -gencode arch=compute_30,code=compute_30 --std=c++11 \
-Xcompiler -Wall -O3 -DNDEBUG "" "" "" "" -m64 -ccbin /usr/bin/cc \
-dlink /some/where/generated_foo.cu.o -o /some/where/foo_intermediate_link.o
nvcc fatal : Don't know what to do with ''
(lines broken and names shortened for readability)
So, the problem is that something triggers CMake to add some empty (quoted) strings to the command-line, which nvcc doesn't like. Other than that the command seems fine.
Now, -O3 -DNDEBUG are my nvcc compilation flags for release builds. But I've certainly not added any empty-string flags anywhere. I tried looking into how FindCUDA constructs the nvcc invocation, but couldn't quite figure out where these empty strings are coming.
Without going into the specifics of my CMakeLists.txt, could this possibly be a well-known issue with CMake's FindaCUDA module which has a general workaround?
Note: I use GNU/Linux Mint 18.3, CMake 3.5, and CUDA 9.1.
It turns out this is a known CMake issue.
The workaround is to only set build-config-specific compilation flags for the active build config, e.g. instead of having:
set(CUDA_NVCC_FLAGS_RELEASE ${CUDA_NVCC_FLAGS_RELEASE} -O3)
set(CUDA_NVCC_FLAGS_DEBUG ${CUDA_NVCC_FLAGS_DEBUG} -g --generate-line-info)
in your CMakeLists.txt, use:
if (CMAKE_BUILD_TYPE_UPPER STREQUAL "RELEASE")
set(CUDA_NVCC_FLAGS_RELEASE ${CUDA_NVCC_FLAGS_RELEASE} -O3)
elseif (CMAKE_BUILD_TYPE_UPPER STREQUAL "DEBUG")
set(CUDA_NVCC_FLAGS_DEBUG ${CUDA_NVCC_FLAGS_DEBUG} -g --generate-line-info)
endif (CMAKE_BUILD_TYPE_UPPER STREQUAL "RELEASE")
instead (or more cases if you have multiple build types).
Another possible alternative is to not use FindCUDA at all, as CMake has added support for CUDA as a "first-class" language beginning with some 3.X release (not sure what X is).
I have a fairly large cmake project that exhibits a compiler error when I use Makefiles generated by CMake 3.9.x:
Scanning dependencies of target client
[ 21%] Building C object
src/lib/client/CMakeFiles/client.dir/client.c.o
In file included from <command-line>:0:0:
/usr/include/stdc-predef.h:40:1: fatal error: compiler.h: No such file or directory
#endif
^
This works properly when using Makefiles generated by CMake 2.8.x. Digging in a bit, I can see that a change was made to the flags.make file generated by CMake between these two versions. The older version used to put -I (include) options in the C_FLAGS variable defined in that file:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 2.8
# compile C with /usr/lib64/ccache/cc
C_FLAGS = -Wall -Wextra -Werror -Wformat=2 -Wundef -mcx16 -Werror-implicit-function-declaration -Wno-unused-parameter -D_GNU_SOURCE -include compiler.h -D__BUG_OUT_AUX=pd_trc_ftl -Wstrict-prototypes -Wdeclaration-after-statement -Wno-tautological-compare -g -I/.../src/lib/client ... -fPIC
C_DEFINES = -DBUILD_NUMBER=\"whatever\" -DBUILD_VERSION=\"1.66.0\" -DCOMMIT_HASH=\"f9bf1c93682f\" -DPDDEBUG -D_FILE_OFFSET_BITS=64
In later versions of CMake the -I options are broken out into their own C_INCLUDES variable:
# CMAKE generated file: DO NOT EDIT!
# Generated by "Unix Makefiles" Generator, CMake Version 3.9
# compile C with /usr/lib64/ccache/cc
C_FLAGS = -Wall -Wextra -Werror -Wformat=2 -Wundef -mcx16 -Werror-implicit-function-declaration -Wno-unused-parameter -D_GNU_SOURCE -include compiler.h -D__BUG_OUT_AUX=pd_trc_ftl -Wstrict-prototypes -Wdeclaration-after-statement -Wno-tautological-compare -g -fPIC
C_DEFINES = -DBUILD_NUMBER=\"whatever\" -DBUILD_VERSION=\"1.66.0\" -DCOMMIT_HASH=\"f9bf1c93682f\" -DPDDEBUG -D_FILE_OFFSET_BITS=64
C_INCLUDES = -I/.../src/lib/client ...
However, in both cases, the including file - build.make - uses only the $(C_DEFINES) $(C_FLAGS), omitting the $(C_INCLUDES) in the newer model:
...
# Include the compile flags for this target's objects.
include src/lib/client/CMakeFiles/client.dir/flags.make
src/lib/client/CMakeFiles/client.dir/client.c.o: src/lib/client/CMakeFiles/client.dir/flags.make
src/lib/client/CMakeFiles/client.dir/client.c.o: ../src/lib/client/client.c
#$(CMAKE_COMMAND) -E cmake_echo_color --switch=$(COLOR) --green --progress-dir=/.../cmake-build-debug/CMakeFiles --progress-num=$(CMAKE_PROGRESS_1) "Building C object src/lib/client/CMakeFiles/client.dir/client.c.o"
cd /.../cmake-build-debug/src/lib/client && /.../contrib/cc/cgcc.sh /.../cmake-build-debug /usr/lib64/ccache/cc sparse ON /.../client-project CMakeFiles/client.dir/client.c.o $(C_DEFINES) $(C_FLAGS) -o CMakeFiles/client.dir/client.c.o -c /.../src/lib/client/client.c
...
Is this a bug in CMake 3.9.x? Has anyone else experienced anything like this when upgrading CMake?
I believe it's possible that we've always done something wrong in our CMakeLists.txt files that just happened to work in the older versions, but that when we upgraded to CMake 3.9.x, suddenly the problem is manifest. Hoping someone has had this issue and figured out what they did wrong.
Thanks in advance!
I'm building a shared library and an application using that lib on Cygwin. With GCC CMake creates a .dll.a to use when linking. Switching to clang I get
[ 34%] Built target xxx_shared
make[2]: *** No rule to make target 'src/libxxx.dll.a', needed by 'xxx.exe'. Stop.
Is this a bug in the clang CMake extension?
I'm using cmake --version 3.3.2
Yes, it seems to be a bug in CMake. Running make VERBOSE=1 reveals that with GCC:
/usr/bin/c++.exe -g -shared -Wl,--enable-auto-import -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
while with clang:
/usr/bin/clang++ -fPIC -g -shared -o XXX -Wl,-Bstatic -lm -Wl,-Bdynamic -lstdc++ -lcygwin -ladvapi32 -lshell32 -luser32 -lkernel32
So it seems that somehow clang++ does not get the -Wl,--enable-auto-import flag. Manually running the corrected clang++ command correctly creates the expected .dll.a allowing the rest of the build to proceed as expected.
Haven't figured out why this happens yet, though. At this point I can't decipher CMakes platform extensions, which seems to set this for GCC.
Update: I've reported this here.
Is there a way to print a list the filenames for the libraries linked into a target via the target_link_libraries command
or even better, have all a target's dependencies copied to a specific folder?
get_target_property(OUT Target LINK_LIBRARIES)
message(STATUS ${OUT})
I realise this doesn't fully answer the question with regards doing it within cmake, but I faced a similar problem and thought I should share my solution.
First, in your source directory ("project"):
$ mkdir build && cd build
$ cmake ..
Then, use graphviz to create a dot file, as in this answer:
$ cmake --graphviz=graph.dot .
Then, strip out the dependencies from the graph for your target (let's call it "foo"):
$ sed -n 's/.*label="\(.*\)"\s.*/\1/p' graph.dot.foo > foo_dependencies.txt
Now, remove the clutter:
$ rm graph.dot*
Actually not(*).
However, you can use a cmake variable to collect the name of the libraries that you want to link (using the set( ... or the list(APPEND ... command), and then use this variable in your target_link_libraries command:
target_link_libraries(<targetname> ${YOUR_CMAKE_VARIABLE})
The same variable can also be used to create your copy commands (for example using this custom target)
(*) A similar question was asked here, and it got no definitive answer.
Well, all linked libraries to a given target TARGET are in the build.../CMakeFiles/TARGET.dir/link.txt.
For instance, TARGET=dirac.x,
.../build_intel17_mkl_i8/.less CMakeFiles/dirac.x.dir/link.txt
There will be a large number of linked libraries:
/cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/bin/intel64/ifort -Wl,-E -w -assume byterecl -g -traceback -DVAR_IFORT -i8 -w -assume byterecl -g -traceback -DVAR_IFORT -i8 -O3 -ip CMakeFiles/dirac.x.dir/src/main/main.F90.o -o dirac.x -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/lib -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/gen1int-build/external/lib -L/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/pelib-build/external/lib -Wl,-rpath,/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/lib:/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/gen1int-build/external/lib:/tmp/milias-work/software/qch/dirac/devel_trunk/build_intel17_mkl_i8/external/pelib-build/external/lib: libobjlib.dirac.x.a src/pelib/libpelib_interface.a external/lib/libstieltjes.a -limf -lsvml -lirng -lstdc++ -lm -lipgo -ldecimal -lstdc++ -lgcc -lgcc_s -lirc -lsvml -lc -lgcc -lgcc_s -lirc_s -ldl -lc external/pcmsolver/install/lib/libpcm.a /usr/lib/x86_64-linux-gnu/libz.so -limf -lsvml -lirng -lstdc++ -lm -lipgo -ldecimal -lstdc++ -lgcc -lgcc_s -lirc -lsvml -lc -lgcc -lgcc_s -lirc_s -ldl -lc /usr/lib/x86_64-linux-gnu/libz.so src/libxcfun_fortran_bindings.a external/xcfun-build/src/libxcfun.a external/lib/libpelib.a libgen1int_interface.a external/lib/libgen1int.a -Wl,--start-group /cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/mkl/lib/intel64/libmkl_lapack95_ilp64.a -lmkl_intel_ilp64 -qopenmp -Wl,--end-group -Wl,--start-group -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread /usr/lib/x86_64-linux-gnu/libm.so -qopenmp -Wl,--end-group external/pcmsolver/install/lib/libpcm.a external/xcfun-build/src/libxcfun.a external/lib/libpelib.a external/lib/libgen1int.a /cvmfs/it.gsi.de/compiler/intel/17.0/compilers_and_libraries_2017.4.196/linux/mkl/lib/intel64/libmkl_lapack95_ilp64.a -lmkl_intel_ilp64 -lmkl_intel_thread -lmkl_core -lpthread /usr/lib/x86_64-linux-gnu/libm.so -lirng -ldecimal -lstdc++