动态库加载：找出未解析符号运行时的简单方法答案

【问题标题】：dynamic library loading : easy way to figure out unresolved symbols runtime动态库加载：找出未解析符号运行时的简单方法
【发布时间】：2013-06-11 02:46:13
【问题描述】：

我正在开发一个大型项目，该项目在运行时使用 ACE_DLL::open 加载动态库。

库已定位并尝试打开，但由于未解析的符号而在 mmap 上失败（下面是 strace ）。我确定这是因为未解析的符号，并且通过运行 nm 我可以获得所有未解析符号的列表。问题是在编译时有大量未解析的符号应该在运行时解决，所以 nm 不是很有帮助，因为我需要一个一个地遍历所有符号。

有没有一种聪明的方法可以准确找出导致 .so 被加载的原因

open("libxxxxxxx_d.so", O_RDONLY) = 29
read(29, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\300w\3\0004\0\0\0"..., 512) = 512
fstat64(29, {st_mode=S_IFREG|0755, st_size=10130306, ...}) = 0
mmap2(NULL, 373832, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 29, 0) = 0xffffffffed5f5000
mmap2(0xed64e000, 12288, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 29, 0x59)  =   0xffffffffed64e000
close(29)                               = 0
munmap(0xed5f5000, 373832)              = 0
munmap(0xed5cc000, 167764)              = 0

【问题讨论】：

是什么让你觉得mmap失败了？

标签： c unix shared-libraries ace

【解决方案1】：

将ACE_DEBUG=1 设置为环境变量，ACE 日志记录应打印一条调试消息，指示哪个符号未解析。这只是一个符号，因此您可能需要多次迭代才能找到所有符号

【讨论】：

完美。找到库后，它会准确打印导致加载失败的未定义符号。现在，如果从 nm 中未定义，我不必经历数百个。

【解决方案2】：

strace 片段没有显示任何类型的故障。共享库的打开似乎已经成功。

我不熟悉你提到的ACE_DLL::open，但我找到了一些信息here，看起来它只是dlopen() 和朋友们的一个薄包装。

现在有可能由于dlopen() 处的未解析符号而导致库无法打开，但前提是使用RTLD_NOW。问题是错误信息只提到了一个有问题的符号。

如果您不想使用 nm 或 objdump -T 或类似方法遍历库所需的符号列表，您可以做的最简单的事情可能是将您的应用程序与相关库链接，然后查看链接器报告为错误。它应该列出所有问题，而不仅仅是一个问题。首先，将一些占位符代码添加到您的应用程序中，该代码将引用库中的任何有效符号（以强制链接器将库拉入），然后将 -lxxxxxxx_d 添加到您的链接选项中。

【讨论】：

【解决方案3】：

此命令将报告共享库中所有缺失的函数和对象：

ldd -r your_library.so

请参阅man ldd 了解更多信息。

【讨论】：