动态依赖 lib/tls 搜索路径答案

【问题标题】：Dynamic dependency lib/tls search path动态依赖 lib/tls 搜索路径
【发布时间】：2014-05-09 13:06:55
【问题描述】：

我有一个依赖于两个基本 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/... 设置链接，我知道boost 是通过b2 的公共调用构建的（即两者的命令行参数完全相同）。 /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 路径？

【问题讨论】：

标签： c++ boost linker glibc ldd

【解决方案1】：

搜索路径在 lib/tls 方面令人费解

你找错树了。

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

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

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

【讨论】：