3

我的目标是通过在编译 boost 时提供dll-path选项来在编译的 boost 库中拥有完整的运行路径：

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

但是，当我检查$(pwd)/build文件夹中的库时，我得到了这个：

$ 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)

即，而不是具有库名称的完整路径，只有库名称（libboost_system.dylib）。应该如何使用dll-path选项或者是否有“官方”方式来实现这一点（除了install_name_tool在每个库上手动运行脚本）？

4

1 回答 1

0

为什么 dll-path 和 hardcode-dll-paths 属性有用？

但是，为了启动依赖于共享库的应用程序，操作系统可能需要在启动应用程序时找到共享库。动态链接器将在系统定义的路径列表中搜索，加载库并解析符号。这意味着您应该更改由 LD_LIBRARY_PATH 环境变量给出的系统定义列表，或者将库安装到系统位置。这在开发时可能很不方便，因为这些库尚未准备好安装，并且可能不希望出现混乱的系统路径。幸运的是，在 Unix 上还有另一种方法。

可执行文件可以包含附加库路径的列表，这些路径将在系统路径之前进行搜索。这非常适合开发，因为构建系统知道所有库的路径，并且可以将它们包含在可执行文件中。当 hardcode-dll-paths 功能具有 true 值（默认值）时，就会执行此操作。当应该安装可执行文件时，情况就不同了。

显然，已安装的可执行文件不应包含指向您的开发树的硬编码路径。（出于这个原因，安装规则明确禁用了 hardcode-dll-paths 功能。）

我对该文档的解释是 Boost 希望它的库安装在标准系统位置。dll-path通过使用和属性，可以使用非标准位置来开发 Boost 本身，但是在 Boost 构建过程hardcode-dll-paths的规则中明确禁用了此功能：install

似乎有几个选项可以在非标准安装位置使用 Boost 共享库：

  1. 根据https://stackoverflow.com/a/33893062/4313507，更新已安装共享库文件中的路径（使用硬编码路径或 RPath）：

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

    请记住，某些 Boost 组件相互链接，因此请务必同时更新内部链接的路径。例子：

    $ 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. 使用LD_LIBRARY_PATH环境变量来帮助定位共享库。例子：

    LD_LIBRARY_PATH=$HOME/local/lib exe_name
于 2018-06-25T20:13:32.320 回答