4

I aim to have full runpaths in compiled boost libraries by providing dll-path option when compiling boost:

$ ./b2 dll-path=$(pwd)/build --prefix=$(pwd)/build
$ ./b2 install dll-path=$(pwd)/build --prefix=$(pwd)/build

However, when I check libraries in $(pwd)/build folder I get this:

$ otool -L build/lib/libboost_system.dylib 
build/lib/libboost_system.dylib:
    libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)
    /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
    /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

I.e. instead of full path with lib name, there is just lib name (libboost_system.dylib). How one should use dll-path option or is there an "official" way to achieve this (other than having a script which manually runs install_name_tool on each library)?

peetonn
  • 2,942
  • 4
  • 32
  • 49

1 Answers1

0

Why are the dll-path and hardcode-dll-paths properties useful?

However, in order for application depending on shared libraries to be started the OS may need to find the shared library when the application is started. The dynamic linker will search in a system-defined list of paths, load the library and resolve the symbols. Which means that you should either change the system-defined list, given by the LD_LIBRARY_PATH environment variable, or install the libraries to a system location. This can be inconvenient when developing, since the libraries are not yet ready to be installed, and cluttering system paths may be undesirable. Luckily, on Unix there is another way.

An executable can include a list of additional library paths, which will be searched before system paths. This is excellent for development because the build system knows the paths to all libraries and can include them in the executables. That is done when the hardcode-dll-paths feature has the true value, which is the default. When the executables should be installed, the story is different.

Obviously, installed executable should not contain hardcoded paths to your development tree. (The install rule explicitly disables the hardcode-dll-paths feature for that reason.)

My interpretation of that documentation is that Boost expects it's libraries to be installed in a standard system location. Non-standard locations can be used for development of Boost itself by using the dll-path and hardcode-dll-paths properties, but this feature is explicitly disabled in the install rule of the Boost build process:

It seems that there are a couple of options for using Boost shared libraries in non-standard install locations:

  1. As per https://stackoverflow.com/a/33893062/4313507 , update the paths in the installed shared library files (using a hard-coded path or RPath):

    install_name_tool libboost_regex.dylib -id @rpath/libboost_regex.dylib

    Keep in mind that some Boost components link to one another, so be sure to update the paths of the internal links as well. Example:

    $ otool -L libboost_filesystem.dylib
libboost_filesystem.dylib:
  libboost_filesystem.dylib (compatibility version 0.0.0, current version 0.0.0)
  libboost_system.dylib (compatibility version 0.0.0, current version 0.0.0)

  2. Use the LD_LIBRARY_PATH environment variable to help locate shared libraries. Example:

    LD_LIBRARY_PATH=$HOME/local/lib exe_name
Dan
  • 71
  • 4