如何确定为什么动态库链接到应用程序？答案

【问题标题】：how to determine why a dynamic library is linked against an application?如何确定为什么动态库链接到应用程序？
【发布时间】：2014-08-21 10:58:30
【问题描述】：

我有一个我正在从源代码构建的 linux 应用程序。当我对二进制文件运行 ldd 时，我了解大多数库......但不是全部。

有没有办法向 ld 或 gcc/g++ 或我能做的任何事情来确定链接器选择链接特定库的原因？

编辑：

为了探索@shloim 设置的路线，我尝试了以下方法：

> nm -u /lib/x86_64-linux-gnu/libcrypto.so.1.0.0
nm: /lib/x86_64-linux-gnu/libcrypto.so.1.0.0: no symbols

> file /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=230ebe6145b6681d0cb7e4c9021f0d899c02e0c4, stripped

nm 不能在 libcrypto 上运行有明显的原因吗？

【问题讨论】：

ldd 是递归的：它列出可执行文件所链接的库、这些库所链接的库、那些库所链接的库，等等. ld 自己什么都不选择，它链接了它被告知的内容。
另请参阅this related question 和所有答案。
libcrypto 已经定义了一切。您应该运行 nm --defined-only .../libcrypto... 和 nm -u
我已经编辑了我的答案
如果您想查看符号，可以使用nm -D。我不知道你为什么想要。符号与原始问题无关。您的可执行文件与您传递给链接器的库完全链接，不多也不少。

标签： linux shared-libraries ld ldd

【解决方案1】：

这应该向您显示 so 文件中使用的所有未在 so 中定义的符号：

nm -u <your_so_file>

然后你可以比较一下

nm --defined-only <3rd_party_so_file>

并尝试找出常见的符号

【讨论】：

谢谢。在原始问题中查看我上面的编辑。

【解决方案2】：

Is there an obvious reason why nm would not work on libcrypto?

一般nm是列出目标文件的符号。这里，nm 用于share object 文件。所以试试这样nm -D libcrypto.so。

readelf 或objdump 也可用于检查shared objects 中存在的符号。

readelf -Ws 将显示所有符号

【讨论】：