c++ - 动态依赖 lib/tls 搜索路径

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/...两个库的设置，我知道 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 路径？

Answer 1

the search path bafflingly differs with respect to lib/tls

你找错人了。

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

一旦加载程序发现，例如RPATH/tls 目录不存在，它从搜索路径中删除该条目(重复搜索不存在的目录没有意义)。最终，您最终只会看到 RPATH 本身。

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