linux - 共享库符号冲突和静态链接(在 Linux 上)

Question

我遇到了一个问题，该问题已在一篇好文章 Shared Library Symbol Conflicts (on Linux) 中详细阐述.问题是当 execution 和 .so 定义了同名函数时，如果 .so 调用这个函数名，它会在执行中调用那个函数，而不是在 .so 本身中调用这个函数。
让我们来谈谈本文中的案例。我明白了DoLayer()函数在 layer.o具有 DoThing() 的外部函数依赖项编译时layer.o .
但是编译时libconflict.so , 不应该就地解析外部函数依赖项，而是将其替换为 conflict.o/DoThing() 的地址静态的？
为什么layer.o/DoLayer()仍然使用动态链接查找DoThing() ?这是一种设计行为吗？

Answer 1

Is this a designed behavior?

是的。
在 UNIX 上引入共享库时，目标是假装它们就像代码在常规(归档)库中一样工作。
假设你有 foo()在 libfoo 中定义和 libbar , 和 bar()在 libbar电话 foo() .
设计目标是 cc main.c -lfoo -lbar无论 libfoo 是否有效，都一样和 libbar是存档或共享库。实现这一目标的唯一方法是拥有 libbar.so使用动态链接解决来自 bar() 的调用至 foo() ，尽管有 foo() 的本地版本.
这种设计使得无法创建一个独立的 libbar.so -- 它的行为(它最终调用哪些函数)取决于链接到进程中的其他函数。这也与 Windows DLL 的工作方式相反。
创建独立的 DSO 在当时并不是一个考虑因素，因为 UNIX 实际上是开源的。
您可以使用特殊的链接器标志更改规则，例如 -Bsymbolic .但是规则很快变得复杂，并且(因为这不是默认设置)您可能会在链接器或运行时加载器中遇到错误。