I've got a cmake file that builds a shared library, a binary, and then links them. This seems to work fine, until I go to run it on the target machine. I was expecting that just the library's name would be defined, and the loader would search for the library along the LD_LIBRARY_PATH, however what I see when I run it is different:
/bin/my_prog: error while loading shared libraries: builds/debug/lib/my_lib.so.2: cannot open shared object file: No such file or directory
src/my_lib/builds/debug/lib is where the library is stored during the build process (created with externalproject_add), but I don't see why it's seemingly picked a random subset of this directory to use as part of the search path.
I've tried playing with the rpath:
set( CMAKE_SKIP_BUILD_RPATH true )
to no avail.
I'm a bit at a loss as to what to try next, as the loader/linker are not my strong suit. What's causing cmake to do this?
Edit:
The cross compile is simply created by using a different toolchain:
toolchain=x86_64-silvermont-linux-gnu
The relevant part of the cmake file:
add_library(dx1 SHARED
src/lib/phy.c
)
ExternalProject_Add(my_lib
BINARY_DIR ${CMAKE_CURRENT_SOURCE_DIR}/my_lib/sdk
CONFIGURE_COMMAND ""
BUILD_COMMAND "make"
INSTALL_COMMAND ""
SOURCE_DIR ${CMAKE_CURRENT_SOURCE_DIR}/my_lib/sdk
LOG_BUILD 1
LOG_OUTPUT_ON_FAILURE 1
BUILD_ALWAYS)
find_library(MY_LIB
NAMES my_lib.so.2
PATHS ${CMAKE_CURRENT_SOURCE_DIR}/my_lib/builds/debug/lib
#PATH_SUFFIXES lib
NO_CMAKE_FIND_ROOT_PATH
NO_CMAKE_PATH
NO_CMAKE_SYSTEM_PATH)
target_link_libraries(dx1 ${MY_LIB} rt)
add_executable(unittest_main src/test/main.c)
target_link_libraries(unittest_main dx1)
Also important to note that the rt library seems to link just fine:
/ # ldd /bin/unittest_main
linux-vdso.so.1 (0x00007ffee53ed000)
libdx1.so => /usr/lib64/libdx1.so (0x00007f756ebe1000)
builds/debug/lib/my_lib.so.2 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f756ebd7000)
libc.so.6 => /lib64/libc.so.6 (0x00007f756ea1b000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f756e9fa000)
/lib64/ld-linux-x86-64.so.2 (0x00007f756ebe8000)
This appears to be a specific issue with the library built with externalproject_add
Related
I'm working on some modifications to the openEMS project. This project uses cmake to build all of its components. The top level CMakeLists.txt file contains the following:
# ...
ExternalProject_Add( openEMS
DEPENDS fparser CSXCAD
SOURCE_DIR ${PROJECT_SOURCE_DIR}/openEMS
CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -DFPARSER_ROOT_DIR=${CMAKE_INSTALL_PREFIX} -DCSXCAD_ROOT_DIR=${CMAKE_INSTALL_PREFIX} -DWITH_MPI=${WITH_MPI} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
)
# ...
Inside the openEMS directory, there's another CMakeLists.txt with the following:
# ...
set(SOURCES
openems.cpp
)
# ...
add_library( openEMS SHARED ${SOURCES})
# ...
After building the project successfully once, make does not rebuild anything when, for example, openems.cpp is modified. Why?
$ mkdir build
$ cd build
$ cmake -DBUILD_APPCSXCAD=NO
$ make
[builds all files]
$ touch ../openEMS/openems.cpp
$ make
[ 33%] Built target fparser
[ 66%] Built target CSXCAD
[100%] Built target openEMS
(noting is built)
I have checked and the modification date of openems.cpp is newer than the target. Even deleting the produced library files and binaries, both in the install directory and in the build directory, does not cause it to rebuild anything. The only way I can get it to rebuild is by deleting everything in the build directory and re-running cmake which, of course, rebuilds everything.
This looks like a case of the following. Quoting from the docs for ExternalProject_Add at the section titled "Build Step Options":
BUILD_ALWAYS <bool>
Enabling this option forces the build step to always be run. This can be the easiest way to robustly ensure that the external project's own build dependencies are evaluated rather than relying on the default success timestamp-based method. This option is not normally needed unless developers are expected to modify something the external project's build depends on in a way that is not detectable via the step target dependencies (e.g. SOURCE_DIR is used without a download method and developers might modify the sources in SOURCE_DIR).
If that's the case, the solution would be to add the BUILD_ALWAYS argument to the ExternalProject_Add call like.
ExternalProject_Add( openEMS
DEPENDS fparser CSXCAD
SOURCE_DIR ${PROJECT_SOURCE_DIR}/openEMS
CMAKE_ARGS -DCMAKE_TOOLCHAIN_FILE=${CMAKE_TOOLCHAIN_FILE} -DFPARSER_ROOT_DIR=${CMAKE_INSTALL_PREFIX} -DCSXCAD_ROOT_DIR=${CMAKE_INSTALL_PREFIX} -DWITH_MPI=${WITH_MPI} -DCMAKE_INSTALL_PREFIX=${CMAKE_INSTALL_PREFIX}
BUILD_ALWAYS TRUE
)
If you confirm that this solves the issue, you might want to raise this as an issue to the maintainers of openEMS.
Also note that since the external project there is using CMake as a buildsystem, you could also add the CONFIGURE_HANDLED_BY_BUILD TRUE to the argument list. See the docs for more info.
Edit: The asker opened a GitHub Pull-Request.
I have an external library. That I am bringing into a CMake build using an imported library target. The build is baking in relative path to the shared library with respect to the CMAKE_BINARY_DIR.
I have something like this:
add_library(libstring UNKNOWN IMPORTED)
set_target_properties(libstring PROPERTIES
IMPORTED_LOCATION "${CMAKE_BINARY_DIR}/external/libstring.so"
)
add_executable(my_exe "${CMAKE_CURRENT_BINARY_DIR}/my_exe.cpp")
target_link_libraries(my_exe PRIVATE libstring)
Then ldd my_exe returns
external/libstring.so => not found
If instead of linking to the imported target I link directly to the library giving the absolute file path it works fine.
target_link_libraries(my_exe PRIVATE "${CMAKE_BINARY_DIR}/external/libstring.so")
Then ldd returns
libstring.so => /<bin-dir>/external/libstring.so (0x00007fce27537000)
In both cases rpath is set to /<bin-dir>/external.
When linking to an imported target how to make CMake bake in just the name of the library in the executable?
Note, that when the imported library path is outside of the binary tree, then the absolute path is baked in the executable.
It turned out that it is not CMake causing this problem, but this particular library.
With Unix Makefiles, CMake passes to the linker relative paths with respect to the CMAKE_CURRENT_BINARY_DIR.
../external/libstring.so
Or with Ninja it passes relative to CMAKE_BINARY_DIR.
external/libstring.so
The linker then bakes-in this whole relative path. Not the name of the library only.
Other libs are not affected even when passed to the linker like that. I don't know what is different with this library.
The solution is to set IMPORTED_NO_SONAME property for the library:
set_property(TARGET libstring PROPERTY IMPORTED_NO_SONAME TRUE)
Documentation for this property says:
Set this property to true for an imported shared library file that has
no soname field. CMake may adjust generated link commands for some
platforms to prevent the linker from using the path to the library in
place of its missing soname.
I am not inexperienced but it's become clear to me that I lack some fundamental understanding in the area of cross-compilation and sysroots. I'm hoping someone can provide me that gem of information I need to continue.
I have downloaded a pre-built armhf gcc cross-compiler/toolchain and it came with a directory called arm-linux-gnueabihf that contains the following directories:
bin/
include/
lib/ - contains libstdc++.a, libgcc_s.so, but does NOT contain `libcrypt.so` or `libcrypt.so.1`, etc.
libc/
Curiously libc contains yet another set of directories, that looks a bit like a separate sysroot, but I'm not sure why it's here. I've looked in other toolchains, including one I built myself with crosstool-ng, and I've not seen anything similar:
libc/
etc/
lib/ - contains files like libcrypt.so.1 / libcrypt-2.24.so
sbin/
usr/
bin/
include/
lib/ - contains files like libc.a, libc.so, libcrypt.a, libcrypt.so,
libexec/
sbin/
share/
var/
Anyway, I'm not sure if that's a problem, or if I have to merge those two sysroots into one
I have installed it within a Docker container at the path /cross-pi-gcc-9.1.0-1. I am using cmake to cross-compile, and my toolchain.cmake file refers to this toolchain:
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
SET(CMAKE_C_COMPILER /cross-pi-gcc-9.1.0-1/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER /cross-pi-gcc-9.1.0-1/bin/arm-linux-gnueabihf-g++)
SET(CMAKE_FIND_ROOT_PATH /cross-pi-gcc-9.1.0-1/arm-linux-gnueabihf/)
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
This seems to be sufficient to build most code with the cross-compiler (including Boost).
As part of this container, I wish to have WiringPi installed in the sysroot, so I can build and link against it.
To do this, I have created a custom CMakeLists.txt file that successfully builds and installs WiringPi:
cmake_minimum_required(VERSION 3.0)
project(WiringPi)
set(CMAKE_THREAD_PREFER_PTHREAD TRUE)
find_package(Threads REQUIRED)
add_library(wiringPi SHARED ads1115.c <snip a bunch of .c files>)
target_include_directories(wiringPi PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})
target_link_libraries(wiringPi PUBLIC ${CMAKE_THREAD_LIBS_INIT} crypt m rt)
install(TARGETS wiringPi DESTINATION lib)
install(FILES ads1115.h <snip a bunch of .h files>
DESTINATION include)
This indicates that the resultant libwiringpi.so should be linked with libcrypt, libpthread, libm and librt. And if I run the target's ldd tool on libwiringpi.so it does indeed show these libraries as dependencies:
$ ldd libwiringPi.so
linux-vdso.so.1 (0x7eee6000)
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so => /usr/lib/arm-linux-gnueabihf/libarmmem-v7l.so (0x76f0a000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0x76ee0000)
libcrypt.so.1 => /lib/arm-linux-gnueabihf/libcrypt.so.1 (0x76ea0000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0x76e1e000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0x76e07000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0x76cb9000)
/lib/ld-linux-armhf.so.3 (0x76f43000)
The problem I'm having is that I have an application that links against wiringpi using a cmake line like this:
target_link_libraries(myapp wiringPi)
When I build this on a raspberry pi using the native toolchain, I don't need to explicitly link against libcrypt. But in my Docker/cross-compiler environment, I get this error at link time:
/cross-pi-gcc-9.1.0-1/bin/arm-linux-gnueabihf-g++ CMakeFiles/app.dir/main.cpp.o -o myapp -lpthread -lwiringPi -lrt
/cross-pi-gcc-9.1.0-1/bin/../lib/gcc/arm-linux-gnueabihf/9.1.0/../../../../arm-linux-gnueabihf/bin/ld: warning: libcrypt.so.1, needed by /cross-pi-gcc-9.1.0-1/bin/../lib/gcc/arm-linux-gnueabihf/9.1.0/../../../../arm-linux-gnueabihf/lib/libwiringPi.so, not found (try using -rpath or -rpath-link)
/cross-pi-gcc-9.1.0-1/bin/../lib/gcc/arm-linux-gnueabihf/9.1.0/../../../../arm-linux-gnueabihf/lib/libwiringPi.so: undefined reference to `crypt#GLIBC_2.4'
collect2: error: ld returned 1 exit status
Note that -lrt and -lpthread seem to have been automatically included in the link library list. But -lcrypt is not present.
If I copy/paste the make VERBOSE=1 output that corresponds to this error, and manually add -lcrypt to the end of the command, it links successfully and the application compilation is complete.
I realise this is a long description but what I'm ultimately trying to do is find the hole in my knowledge that is preventing me from understanding why I would need to explicitly link libcrypt into this application in this environment.
I would have thought, perhaps wrongly, that since libwiringpi.so is already linked against libcrypt, that it wouldn't need to be linked at the top level. If that's not how it works, is there anyone that can help me repair my mental model, please?
Note: I could just add target_link_libraries(myapp wiringPi crypt) however I don't think it's necessary (not needed when building natively) and I'd like to learn a bit more about the process rather than just finding a workaround.
Answering this myself...
It looks like the presence of the libc directory in the sysroot is unusual, and I checked other toolchains and it was always merged with lib. So I ended up ditching that particular toolchain and building my own with crosstool-ng instead. This avoided the problem entirely. It would be nice to understand how I might have got this working, but for now I must move on.
Note that I had success with just using CMAKE_SYSROOT only - no need in my case to specify CMAKE_FIND_ROOT_PATH and friends.
I am using CLion editor (with CMake) for my C project,
I've never used an external library though,
my question is how do I link an external lib (for ex. libxml2) to my project?
I've seen some questions similar to this but none worked for me.
My project is compiled on Windows, and I have libxml .dll, include, and .lib files(binaries for Windows).
Edit: My CMakeLists.txt file after the answer suggested:
cmake_minimum_required(VERSION 3.2)
project(time_table)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
set(SOURCE_FILES
course.c
course.h
day.h
defines.h
find_tables.c
find_tables.h
item.h
parse_info.c
parse_info.h
table.c
table.h
time_table.c grades.c grades.h)
link_libraries(C:/Users/Gal/Desktop/time_table/libxml2-2.7.8.win32/lib)
add_executable(time_table ${SOURCE_FILES})
target_link_libraries(time_table libxml2)
and this is what I get:
"C:\Program Files (x86)\JetBrains\CLion 1.1.1\bin\cmake\bin\cmake.exe" --build C:\Users\Gal\.clion11\system\cmake\generated\2eda76ff\2eda76ff\Debug --target time_table -- -j 8
[ 14%] Linking C executable time_table.exe
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: cannot find -llibxml2
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[3]: *** [time_table.exe] Error 1
CMakeFiles\time_table.dir\build.make:225: recipe for target 'time_table.exe' failed
CMakeFiles\Makefile2:66: recipe for target 'CMakeFiles/time_table.dir/all' failed
mingw32-make.exe[2]: *** [CMakeFiles/time_table.dir/all] Error 2
CMakeFiles\Makefile2:78: recipe for target 'CMakeFiles/time_table.dir/rule' failed
mingw32-make.exe[1]: *** [CMakeFiles/time_table.dir/rule] Error 2
What is wrong?
There is a key work for libraries installed on your machine. <lib_name>_INCLUDE_DIR and <lib_name>_LIBRARIES once you have done find_package. This works for me.
find_package(LibXml2 REQUIRED)
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/<my_stuff> ${LIBXML2_INCLUDE_DIR})
add_executable(<my_exe> <my_source_files>)
target_link_libraries(<my_exe> ${LIBXML2_LIBRARIES})
---- Just a note for your curiosity ----
If you ever needed to build (1) a (static) library of your calculations, maybe reusable, and (2) an executable that uses that library and LIBXML2, do this.
find_package(LibXml2 REQUIRED)
# add a calculation library: file "lib<mycalc>.a"
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/<your header files folder> ${LIBXML2_INCLUDE_DIR})
add_library(<mycalc> STATIC ${CMAKE_CURRENT_SOURCE_DIR}/<your src files folder>)
target_link_libraries(<mycalc> ${LIBXML2_LIBRARIES})
# add the executable: file <my_exe>
include_directories(${CMAKE_CURRENT_SOURCE_DIR}/<your header files folder> ${LIBXML2_INCLUDE_DIR})
add_executable(<my_exe> <your exe src files>)
target_link_libraries(<my_exe> <mycalc> ${LIBXML2_LIBRARIES})
Assume that full path to the library(.lib) can be expressed as
<library_dir>/<library_name>.lib
For compile executable, which uses this library, you need:
CMakeLists.txt:
link_libraries(<library_dir>)
add_excutable(<my_exe> ..)
target_link_libraries(<my_exe> <library_name>)
For use(run) compiled executable, you need to have <library_name>.dll either under one of the directory, listed in the PATH environment variable, or within same directory with executable.
there are 32bit and 64bit version of libxml2, to be found here.
you can put them below the PATH - or the C:\Windows directory.
With moderns CMake (version 3.2 or newer), it got much easier:
Search for the library. CMake has an according find module, thus it boils down to
find_package(LibXml2 REQUIRED)
Then you can link the library it to your target foo
target_link_libraries(foo PUBLIC LibXml2::LibXml2)
That's it folks! No fiddling around with headers and libraries, all done automatically.
If you have not installed the library, you might want to set LibXml2_DIR to the location where LibXml2 is located, i.e., by passing -DLibXml2_DIR=C:\software\libxml2 to your CMake call. That will help CMake finding LibXml2.
I am trying to get rid of setting LD_LIBRARY_PATH everytime time I run my program. After adding in the library and targeting my executable to the library, when I run it tells me it can not open shared object library, no such file or directory.
In my CMakeLists.txt I have:
add_library(heart SHARED ${HEART_FILES})
add_executable(run ${RUN_FILES})
target_link_libraries(run heart)
set(CMAKE_SKIP_BUILD_PATH FALSE)
set(CMAKE_BUILD_WITH_INSTALL_RPATH FALSE)
set(CMAKE_INSTALL_RPATH "~/person/target/usr/local/lib")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
I set an absolute link to my library folder to test out whether this would create an rpath to my library and it seems like there isn't. I have checked and made sure that the shared library is indeed in lib. libheart.so is the file that is being linked. What else am I missing?
It is because you build heart and run from the same cmake project:
CMAKE_INSTALL_RPATH_USE_LINK_PATH is an interesting and very useful option. When building a target with RPATH, CMake determines the RPATH by using the directories of all libraries to which this target links. Some of these libraries may be located in the same build tree, e.g. libbar.so, these directories are also added to the RPATH.
If this option is enabled, all these directories except those which are also in the build tree will be added to the install RPATH automatically. The only directories which may then still be missing from the RPATH are the directories where the libraries from the same project (i.e. libbar.so) are installed to. If the install directory for the libraries is not one of the systems default library directories, you have to add this directory yourself to the install RPATH by setting CMAKE_INSTALL_RPATH accordingly
You can try this:
SET(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
More documentation here cmake rpath handling
EDIT:
Only this should work:
set(CMAKE_VERBOSE_MAKEFILE ON)
set(CMAKE_INSTALL_RPATH "${CMAKE_INSTALL_PREFIX}/lib")
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)
add_library(heart SHARED ${HEART_FILES})
add_executable(run ${RUN_FILES})
target_link_libraries(run heart)
install(
TARGETS heart run
RUNTIME DESTINATION bin
LIBRARY DESTINATION lib
)
Clean your build directory and then:
cmake -G "Unix Makefiles" -DCMAKE_INSTALL_PREFIX=/home/person/target/usr/local ..
make install
At the end of the g++ line Linking CXX executable run you should see like -Wl,-rpath,/home/person/target/usr/local/lib
If you want a fully relocatable package:
set(CMAKE_INSTALL_RPATH "$ORIGIN/../lib")
PS: are you sur that it is libheart.so that is not found ?
In your CMake file, set the RPATH before defining the targets. The CMAKE_INSTALL_RPATH must be defined before calling add_executable(), otherwise it has no effect.
I had a similar issue as the original post. I created executables which linked to external shared libraries. This approach compiled and executed fine from the build directory. However, the executable that was installed to a separate directory could not find a shared library at runtime:
error while loading shared libraries: libxxxx.so.1: cannot open shared object file: No such file or directory
To solve, I
1) upgraded to CMake 3.17
2) used Craig Scott's recommended:
set(CMAKE_INSTALL_RPATH $ORIGIN)
as explained in his talk
3) set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE) as directly mentioned to solve this error in the second common question in Kitware's documention
4) Put all this before adding the targets as mentioned in this post
5) Used the "$ORIGIN/../lib" syntax instead of Craig's Scott's mentioned $ORIGIN as mentioned by #explo91
In summary, and to my suprise, only the "$ORIGIN/../lib" before the target definition was necessary from above (I tested the other combinations which did not fix the cannot open shared object file runtime issue).
Anyway the solution I finally applied, which may be of better, fine-grained CMake style or at least may be helpful to others on their RPATH journey is:
set_target_properties(target_defined_above PROPERTIES INSTALL_RPATH "$ORIGIN/../lib")