我正在尝试编译一个二进制文件，将其与静态库libfoo.a：
连接起来gcc -L. -o myapp myapp.o -lfoo
但我从链接器收到以下错误：
libfoo.c:101: undefined reference to `_TRACE'
问题是我没有libfoo.a库的源代码。
我试图在库中获得_TRACE符号的引用，我得到了这个：
nm libfoo.a | grep TRACE
U _TRACE
假设_TRACE不会影响libfoo.a中的内部工作，是否可以让链接器为此符号定义一些占位符值，以便我可以编译我的代码？
答案 0 :(得分：2)
假设
中的内部工作原理_TRACE不会影响libfoo.a
这似乎是一个不合理的希望假设。
是否可以让链接器为此符号定义一些占位符值，以便我可以编译我的代码？
首先要检查libfoo的文档。静态库依赖于用户期望定义的符号是不常见的;事实上，这种安排与传统的连接器不能完全一致。我看到几个看似合理的解释：
您需要在libfoo之后链接其他（特定）库以提供该符号的定义。
使用libfoo的代码需要#include一个关联的标头，该标头提供了_TRACE的暂定定义。
使用libfoo的程序需要使用特定的工具链和特定选项构建。
它刚刚破碎。
仅在情况（4）中尝试手动提供相关符号的定义是合适的，在这种情况下，最好的办法是按照情况（1）或多或少地进行，通过构建一个对象来提供定义并将其链接到库之后。当然，这会让你试图猜测定义应该是什么。
如果_TRACE是一个全局变量，那么即使库需要不同大小的整数或具有不同签名的整数，也可以将其定义为初始值为0的intmax_t。但是，如果它应该是一个功能，那么你可能是吐司。它可能有太多的签名，对行为的期望太多。没有理由认为你可以提供合适的占位符。
答案 1 :(得分：0)
我怀疑，_TRACE函数是一种调试函数。而且我认为它不会影响libfoo.a的内部运作。
我解决了将_TRACE函数定义为：
int _TRACE(char*, ...) { return 0; }
当然，这个解决方案只是暂时的，不能在生产中使用，但它符合我编译代码的目的。