Question

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

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

即。而不是lib名称的完整路径，只有lib名称（libboost_system.dylib）。如何使用dll-path选项或是否有＃34;官员＆＃34;实现这一目标的方法（除了在每个库上手动运行install_name_tool的脚本之外）？

Answer 1

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

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

可执行文件可以包含其他库路径的列表，将在系统路径之前进行搜索。这对于开发非常有用，因为构建系统知道所有库的路径并将其包含在可执行文件中。当hardcode-dll-paths功能具有默认值true时，将完成此操作。应该安装可执行文件时，情况就不同了。

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

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

在非标准安装位置使用Boost共享库似乎有两种选择：

根据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)

使用LD_LIBRARY_PATH环境变量来帮助查找共享库。示例：
```
LD_LIBRARY_PATH=$HOME/local/lib exe_name
```

＆＃34; DLL-路径＆＃34;在建立提升时没有效果

1 个答案: