共享库符号冲突和静态链接（在Linux上） [英] Shared library symbol conflicts and static linking (on Linux)

问题描述

我遇到了一篇好文章共享库符号冲突（在Linux上）。问题在于，当执行和.so定义了相同的名称函数时，如果.so调用此函数名称，它将在执行时调用该函数名称，而不是在.so本身中调用该函数名称。

I'm encountering an issue which has been elaborated in a good article Shared Library Symbol Conflicts (on Linux). The problem is that when the execution and .so have defined the same name functions, if the .so calls this function name, it would call into that one in execution rather than this one in .so itself.

让我们在本文中讨论此案。我了解 layer.o 中的 DoLayer（）函数具有 DoThing的外部函数依赖性（），当编译 layer.o 时。

Let's talk about the case in this article. I understand the DoLayer() function in layer.o has an external function dependency of DoThing() when compiling layer.o.

但是，当编译 libconflict时.so ，不应就地解析外部函数依赖项，而应仅用 conflict.o / DoThing（）的地址替换？

But when compiling the libconflict.so, shouldn't the external function dependency be resolved in-place and just replaced with the address of conflict.o/DoThing() statically?

为什么 layer.o / DoLayer（）仍使用动态链接来查找 DoThing（） ？这是设计行为吗？

Why does the layer.o/DoLayer() still use dynamic linking to find DoThing()? Is this a designed behavior?

推荐答案

这是设计行为吗？

Is this a designed behavior?

是。

在UNIX上引入共享库时，目标是假装它们像代码一样工作

At the time of introduction of shared libraries on UNIX, the goal was to pretend that they work just as if the code was in a regular (archive) library.

假设您在两个 libfoo <中都定义了 foo（） / code>和 libbar ，以及 libbar bar（） c $ c>调用 foo（）。

Suppose you have foo() defined in both libfoo and libbar, and bar() in libbar calls foo().

设计目标是 cc main.c -lfoo -lbar 的工作原理相同，而不管 libfoo 和 libbar 是存档还是共享库。实现此目的的唯一方法是让 libbar.so 使用动态链接来解决来自 bar（）的调用到 foo（），尽管本地版本为。

The design goal was that cc main.c -lfoo -lbar works the same regardless of whether libfoo and libbar are archive or a shared libraries. The only way to achieve this is to have libbar.so use dynamic linking to resolve call from bar() to foo(), despite having a local version of foo().

此设计使其无法创建独立的 libbar.so -其行为（最终调用的功能）取决于其他功能链接到流程中。这也与Windows DLL的工作方式相反。

This design makes it impossible to create a self-contained libbar.so -- its behavior (which functions it ends up calling) depends on what other functions are linked into the process. This is also the opposite of how Windows DLLs work.

由于UNIX实际上是开源的，因此当时不考虑创建独立的DSO。

Creating self-contained DSOs was not a consideration at the time, since UNIX was effectively open-source.

您可以使用特殊的链接程序标志来更改规则，例如 -Bsymbolic 。但是规则变得非常复杂，并且（因为这不是默认设置），您可能会在链接程序或运行时加载程序中遇到错误。

You can change the rules with special linker flags, such as -Bsymbolic. But the rules get complicated very quickly, and (since that isn't the default) you may encounter bugs in the linker or the runtime loader.

这篇关于共享库符号冲突和静态链接（在Linux上）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！