在 Linux 中测试外部未定义的引用答案

【问题标题】：Test for external undefined references in Linux在 Linux 中测试外部未定义的引用
【发布时间】：2010-05-03 21:11:47
【问题描述】：

是否有内置的 linux 实用程序可用于测试新编译的共享库以查找外部未定义引用？ Gcc 似乎足够智能，可以检查我自己的二进制文件中未定义的符号，但如果该符号是对另一个库的引用，gcc 不会在链接时检查。相反，当我尝试从另一个程序链接到我的新库时，我只会收到该消息。

当我编译一个不同的项目时，在库中获得未定义的参考消息似乎有点愚蠢，所以我想知道在我构建库时是否可以检查所有内部和外部引用，而不是在我链接到时它。

示例错误：

make -C  UnitTests debug
make[1]: Entering directory `~/projects/Foo/UnitTests`
g++ [ tons of objects ] -L../libbar/bin -lbar -o UnitTests
libbar.so: undefined reference to `DoSomethingFromAnotherLibrary`
collect2: ld returned 1 exit status
make[1]: *** [~/projects/Foo/UnitTests] Error 1

【问题讨论】：

标签： c++ linux linker

【解决方案1】：

通常，链接共享对象时允许未定义的引用，但如果您要链接的对象文件中存在未定义的符号以创建共享库，则可以通过向链接器提供 -z defs 使链接器生成错误（或在调用链接器的 gcc 命令中等效为 -Wl,-z,defs）。

【讨论】：

哈哈，太棒了。现在我可以知道在编译库时是谁在调用未定义的函数！链接到库时比通用消息要好得多。干杯!我有点好奇为什么 ld 现在允许共享库中未解析的外部..
@Charles：共享对象符号可能（如果不寻常）由可执行文件中的对象文件中的符号解析，因此-z defs 可能并不总是您想要的。也有可能在最终链接时使用的库版本可能不是在最终链接或加载时使用的版本，因此即使-z defs 在构建过程的早期生成错误，最终链接也可能有效。在我创建共享对象的大多数情况下，-z defs 可以工作并且很有用。