I built my shared library(I use a lib calculating the fibonacci number for example) myself and want to use it in my another c++ project built by CMake
Let's say the shared library and headers located in /path/to/my/lib
, the shared library libfib.so
is in /path/to/my/lib/lib
and the header fib.h
is in /path/to/my/lib/include
and my own project located in /path/to/my/project
Here is my original CMakeLists.txt
:
cmake_minimum_required(VERSION 3.2)
project(learn-lib)
set(CMAKE_CXX_FLAGS "-std=c++11 ${CMAKE_CXX_FLAGS}")
set(FIB_INCLUDE "${FIB_PREFIX}/include")
set(FIB_LIB "${FIB_PREFIX}/lib")
set(EXE mybin)
include_directories(${FIB_INCLUDE})
link_directories(${FIB_LIB})
add_executable(${EXE} main.cpp)
target_link_libraries(${EXE} fib)
install(TARGETS ${EXE} RUNTIME DESTINATION bin)
And I use this script to build and install my project:
mkdir -p build_dir
cd build_dir
cmake -DFIB_PREFIX=/path/to/my/lib \
-DCMAKE_INSTALL_PREFIX=/path/to/my/project \
..
make
make install
cd ..
Now, after running the install script, I got two executables, one in build_dir
, one in the install location path/to/my/project/bin
, when running the program in build_dir
, everything is fine, but when running the installed program, I get:
./bin/mybin: error while loading shared libraries: libfib.so: cannot open shared object file: No such file or directory
After some searching on google and stackoverflow, I knew it seems that CMake
removed the runtime search path that is tied to the executable when building. I now know two ways to get it around:
- Add the library path where
libfib.so
locates to the environment variableLD_LIBRARY_PATH
- Add
set_target_properties(${EXE} PROPERTIES INSTALL_RPATH_USE_LINK_PATH TRUE)
into myCMakeLists.txt
So, my questions are:
- Why is
CMake
designed so? When installing, why would it remove runtime path from executables instead of just copying the built executables to the install destination or whatever keeping the link path for the installed program? - Which way is the best practice(or is there a best practice) to eliminate this problem? To set the environment or to add
set_target_properties(...)
intoCMakeLists.txt
?
You may want to look into CMake's RPATH handling settings
This quote in particular seems relevant to your predicament:
You can set the RPATH that is set for installed binaries using the
CMAKE_INSTALL_RPATH
variable, for example:and you can also disable the RPATH stripping during installation:
I just want to answer question 1. The why this is done. Alex already posted a solution how to change this behaviour.
The reason is that when you build it you really want to use the libraries the build script saw on your machine. If you build a whole stack of libraries for your app you want no mistake that they aren't picked by the library. Therefore it makes sense to use the full rpath to the library. Also you never move your application around between compilation and when it's debugged and run.
But when installed the usual case in the unix world was to use the shared /usr/lib and /usr/local/lib directories. They are usually picked up (unless LD_LIBRARY_PATH is used) and thats normally what you want.
As you see by my wording, all this is a mess because it includes so many implicit decisions how you organize your build and your deployment. It is one of the reasons why the term 'DLL hell' once only popular on Windows moved over to Unix when it became more widely used. There is no technical solution because its not a technical problem (that part is solved). Its an organizational problem and CMake has to decide about the one flavour it supports on a platform by default. And IMHO they have choosen wisely.