Question

我有一个可执行文件，它依赖于两个基本的boost库libboost_system和libboost_thread，当可执行文件加载库时，搜索路径在lib/tls方面有些不同：

 $ LD_DEBUG=libs ./var.exe
 25130:     find library=libboost_system.so.1.55.0 [0]; searching
 25130:      search path=/opt/boost_1_55_0/stage/lib/tls/x86_64:/opt/boost_1_55_0/stage/lib/tls:/opt/boost_1_55_0/stage/lib/x86_64:/opt/boost_1_55_0/stage/lib         (RPATH from file ./var.exe)
 25130:       trying file=/opt/boost_1_55_0/stage/lib/tls/x86_64/libboost_system.so.1.55.0
 25130:       trying file=/opt/boost_1_55_0/stage/lib/tls/libboost_system.so.1.55.0
 25130:       trying file=/opt/boost_1_55_0/stage/lib/x86_64/libboost_system.so.1.55.0
 25130:       trying file=/opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0
 25130:
 25130:     find library=libboost_thread.so.1.55.0 [0]; searching
 25130:      search path=/opt/boost_1_55_0/stage/lib            (RPATH from file ./var.exe)
 25130:       trying file=/opt/boost_1_55_0/stage/lib/libboost_thread.so.1.55.0

可执行文件已经与两个库的-rpath=/opt/...设置完全相同，我知道通过b2的公共调用构建了boost（即两者的命令行参数完全相同））。 /etc/ld.so.cache没有任何相关条目。

此外，就rpath或ABI要求而言，构建的库本身并没有什么值得注意的，

$ readelf -d /opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0 | grep -i rpath
# empty
$ eu-readelf -h /opt/boost_1_55_0/stage/lib/libboost_system.so.1.55.0
# there is no difference in ABI versions

除了libboost_thread取决于libboost_system这两个库都需要GLIBC_2.2.5之外，两个库都具有完全相同的共享库依赖关系。

我认为确定libboost_system需要以某种方式与 NPTL glibc相关联，以及为什么会搜索<rpath>/lib/tls，但是对于我来说，查看libboost_system库的objdump是不是很明显。

如何标记NPTL库？ dlopen（3）如何决定查看lib / tls路径？

Answer 1

搜索路径与lib / tls相比有些不同

你正在咆哮错误的树。

GLIBC加载程序从您的可执行文件中获取RPATH，并在其中附加PLATFORM个字符串（tls/x86_64:tls:x86_64）以构建完整的搜索路径。

一旦加载程序发现例如RPATH/tls目录不存在，它从搜索路径中删除该条目（重复搜索不存在的目录没有意义）。最终你最终只有RPATH存在。

如果您将二进制文件重新链接到例如颠倒libboost_thread和libboost_system上的依赖顺序，您将再次发现RPATH/tls等中仅搜索第一个库，而{{1}中只搜索第二个库}}

动态依赖lib / tls搜索路径

1 个答案: