将程序链接到共享对象时，ld 将确保可以解析符号。这基本上保证了程序与其共享对象之间的接口是兼容的。在阅读了Linking with dynamic library with dependencies 之后，我了解到ld 将下降到链接的共享对象并尝试解析它们的符号。
当共享对象本身链接时，我的共享对象的引用不是已经检查了吗？
我可以理解在链接时找出程序是否具有启动所需的所有部分的吸引力，但是在共享对象可能单独分发的包构建的上下文中这似乎无关紧要（Debian 的 lib* 包，例如）。它在对执行构建程序不感兴趣的系统上引入了递归构建依赖项。
我可以相信构建共享对象时解决的依赖关系吗？如果是这样，在构建我的程序时使用 -unresolved-symbols=ignore-in-shared-libs 有多安全？
【问题讨论】：
标签： linker dependencies ld
您想知道为什么程序的链接要费心去解析源自 与其链接的共享库，因为：
当共享对象本身链接时，我的共享对象的引用不是已经检查了吗？
不，它们不是，除非您在链接共享库时明确坚持，
这里我要建一个共享库libfoo.so：
foo.c
extern void bar();
void foo(void)
{
bar();
}
例行编译链接：
$ gcc -fPIC -c foo.c
$ gcc -shared -o libfoo.so foo.o
没问题，bar 未定义：
$ nm --undefined-only libfoo.so | grep bar
U bar
我需要坚持让链接器反对：
$ gcc --shared -o libfoo.so foo.o -Wl,--no-undefined
foo.o: In function `foo':
foo.c:(.text+0xa): undefined reference to `bar'
当然：
main.c
extern void foo(void);
int main(void)
{
foo();
return 0;
}
它不会让我将libfoo 链接到一个程序：
$ gcc -c main.c
$ gcc -o prog main.o -L. -lfoo
./libfoo.so: undefined reference to `bar'
除非我也在同一个链接中解析bar：
bar.c
#include <stdio.h>
void bar(void)
{
puts("Hello world!");
}
也许通过从另一个共享库获取它：
gcc -fPIC -c bar.c
$ gcc -shared -o libbar.so bar.o
$ gcc -o prog main.o -L. -lfoo -lbar
然后一切都很好。
$ export LD_LIBRARY_PATH=.; ./prog
Hello world!
它是共享库的本质，默认情况下它没有 在链接时解析其所有符号。这样一来，程序 - 通常确实需要它的所有符号解析一个链接时间 - 可以获得它的所有符号 通过与多个库链接来解决。
【讨论】：
-Wl,--no-undefined 传递给链接器吗？
我的共享对象的引用不是已经检查了吗 共享对象本身何时链接？
嗯，共享库可能已与 -Wl,--allow-shlib-undefined 或虚拟依赖项链接，因此检查它们仍然有意义。
我可以相信构建共享对象时解决的依赖关系吗？
可能不是，当前的链接环境和链接原始shlibs的环境可能不同。
如果是这样，使用 -unresolved-symbols=ignore-in-shared-libs 有多安全 在构建我的程序时？
在这种情况下，您可能会遗漏潜在的错误（或者将它们延迟到运行时，这仍然很糟糕）。想象这样一种情况，共享对象所需的一些符号来自可执行文件本身或来自可执行文件链接的库之一（但 不是 由缺少符号的 shlib 链接）。
编辑
虽然上面是正确的，但 Mike Kinghan 的回答给出了更有力的论据，支持在可执行链接期间在库中解析符号。
【讨论】：