The correct link command is
g++ file1.o file2.o xxx.0 -o target -I./ -I/usr/local/libmylibone/
-L./ -L/usr/local/testlib/ ../lib/special_lib/static_lib.a
-lasn1c++ -lmysqlclient -lnsl -lm -lz -lc -ldl -lpthread -lrt -ljson
Please focus on ../lib/special_lib/static_lib.a, this is a static library and not named with libxxx.a. And I don't know how to write a CMake command to get this correct link command.
I've tried TARGET_LINK_LIBRARIES(../lib/special_lib/static_lib.a) and it will be translated to -l../lib/special_lib/static_lib.a. I've also tried TARGET_LINK_LIBRARIES(static_lib) but got -lstatic_lib and failed.
If you put the absolute path to your library it should work:
TARGET_LINK_LIBRARIES(your_binary /usr/local/lib/static_lib.a)
Second option:
ADD_LIBRARY(staticlib STATIC IMPORTED)
SET_TARGET_PROPERTIES(staticlib PROPERTIES IMPORTED_LOCATION /usr/local/lib/static_lib.a)
TARGET_LINK_LIBRARIES(your_binary staticlib)
The official CMake documentation for importing/exporting targets is here.
Related
my CMakeLists.txt is as follows
find_pacakge(something)
add_executable(exe main.cc)
# libsomething depends on dlopen/dlsym... so I have to add dl here
target_link_libraries(run PRIVATE something::something dl)
results:
g++ -o exe -ldl path/to/libsomething.a
libsomething.c: undefined reference to `dlsym'
but CMake always put the -ldl flag before libsomething.a even I have tried:
target_link_libraries(run PRIVATE dl something::something dl something::something )
# produced output:
# g++ -o exe -ldl -ldl path/to/libsomething.a
# libsomething.c: undefined reference to `dlsym'
or
target_link_libraries(run PRIVATE dl)
target_link_libraries(run PRIVATE something::something)
target_link_libraries(run PRIVATE dl)
# produced output:
# g++ -o exe -ldl -ldl path/to/libsomething.a
# libsomething.c: undefined reference to `dlsym'
But the right way to build the program is
$ g++ -o exe path/to/libsomething.a -ldl
How can I resolve this issue?
Your comment
# libsomething depends on dlopen/dlsym... so I have to add dl here
reveals the core of the problem: It is libsomething needs linkage with dl, so its find_package(something) should care about that. The absence of that linkage is a deficiency (that is, a bug) in the library itself.
If you are the author of the library, then fix it.
If the author of the library accepts bugreports, then fill the one about given problem.
If fixing the library is not an option for you, then you could "fix" result of find_package in your project:
find_package(something)
# Created imported target misses linkage with 'dl' library.
# Add it here.
target_link_libraries(something::something INTERFACE ${CMAKE_DL_LIBS})
add_executable(exe main.cc)
# Now we can use the library in a simple way
target_link_libraries(exe PRIVATE something::something)
The above code relies on the fact, that something::something, provided by find_package(something), is an IMPORTED target, denoting the library file. So we can add required linkage to it.
I can compile my project by running
g++ main.cpp -l:libpj-x86_64-unknown-linux-gnu.a -lpthread -lm -luuid
or
g++ main.cpp /usr/local/lib/libpj-x86_64-unknown-linux-gnu.a -lpthread -lm -luuid
But when I try adding library with either one of:
meson.get_compiler('cpp').find_library('libpj-x86_64-unknown-linux-gnu.a')
meson.get_compiler('cpp').find_library('/usr/local/lib/libpj-x86_64-unknown-linux-gnu.a')
I'm getting error:
ERROR: C++ library 'libpj-x86_64-unknown-linux-gnu' not found
Solution was to add 'dirs' variable even tho file is in standard /usr/local/lib path and to remove .a extension.
cc.find_library('libpj-x86_64-unknown-linux-gnu', dirs: '/usr/local/lib/')
Later of course lib was available inside meson and was added to executable and tested.
I am trying to use cmake to link intel mkl for my code. From mkl link advisor, I should link the library by:
-L${MKLROOT}/lib/intel64 -lmkl_intel_lp64 -lmkl_core -lmkl_sequential -lpthread -lm -ldl
I then write a module to find mkl_intel_lp64, mkl_core, and mkl_sequential in Findmkl.cmake:
find_library(lp64_libraries NAMES mkl_intel_lp64 PATHS "${mkl_path}/lib/intel64")
find_library(core_libraries NAMES mkl_core PATHS "${mkl_path}/lib/intel64")
find_library(sequential_libraries NAMES mkl_sequential PATHS "${mkl_path}/lib/intel64")
Then I can link these libraries. While I do not know how to link -lpthread -lm -ldl, I am not sure what this link mean, I can not find any libpthread.a in $MKLROOT/lib/intel64.
Those libraries should exist on each Unix system.
So you can just add:
target_link_libraries(target_name m dl pthread)
I'm trying to create static library with link time optimization using cmake and g++.
set(
CMAKE_CXX_FLAGS
"${CMAKE_CXX_FLAGS} -Wall -Werror -Wextra -pedantic -std=c++11"
)
if (CMAKE_COMPILER_IS_GNUCXX)
set(
CMAKE_STATIC_LINKER_FLAGS_RELEASE
"${CMAKE_STATIC_LINKER_FLAGS_RELEASE} -flto -fwhole-program"
)
endif()
add_library(
mylib STATIC
mylib.cpp
)
But when running typical
cmake -DCMAKE_BUILD_TYPE=Release ..
make
I'm getting following error:
/usr/bin/ar: two different operation options specified
link.txt file contains following commands:
/usr/bin/ar cq libmylib.a -flto -fwhole-program CMakeFiles/mylib.cpp.o
/usr/bin/ranlib libmylib.a
From what I understand from running ar --help the -flto -fwhole-program should be before libmylib.a in the first line. But I have no idea how to force CMake to put it there.
Is my assumption correct? And how can I resolve this?
EDIT: I'd like to add that I'm completely new to using LTO so if it doesn't make sense to use it for static libraries, please do tell me so.
-flto isn't a valid option for ar. You should instead use these flags for CMAKE_EXE_LINKER_FLAGS.
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++