动态链接库可以覆盖静态库吗？ [英] Can a dynamically linked library override a static one?

问题描述

nokogori gem带有自己的 libxml2 版本。此外，它警告约 libxml2.so 之前需要加载的其他版本：

nokogori gem comes with its own version of libxml2. Moreover it warns about libxml2.so of a different version being loaded before it was required:

      if compiled_parser_version != loaded_parser_version
        ["Nokogiri was built against LibXML version #{compiled_parser_version}, but has dynamically loaded #{loaded_parser_version}"]

基本上是比较 LIBXML_DOTTED_VERSION 宏和 xmlParserVersion 全局变量：

It basically compares LIBXML_DOTTED_VERSION macro and xmlParserVersion global variable:

rb_const_set（mNokogiri，
rb_intern（ LIBXML_VERSION），
NOKOGIRI_STR_NEW2（LIBXML_DOTTED_VERSION）
）;
rb_const_set（mNokogiri，
rb_intern（ LIBXML_PARSER_VERSION），
NOKOGIRI_STR_NEW2（xmlParserVersion）
）;


我是亲身体验的。当 rmagick （动态链接到 libxml2.so 时）， ldd 确认在 nokogiri 之前是必需的，后者会抱怨。

And I'm experiencing it firsthand. When rmagick (which dynamically links to libxml2.so, ldd confirms that) is required before nokogiri, the latter complains.

从我看到的 nokogiri 静态链接到 libxml2 。首先，它是默认（应该）。然后，当不需要 rmagick 时，在 / proc /中看不到 libxml2.so PID /地图。我都看不到 libxml2.so 的另一个版本。 ldd 没有将 libxml2.so 列为 nokogiri.so 的依赖关系。 objdump 列出 xmlReadMemory （和朋友）作为 nokogori.so 的符号（可能是它是静态链接的符号）

From what I can see nokogiri is linked to libxml2 statically. First that is the default (supposedly). Then when rmagick is not required I can't see libxml2.so in /proc/PID/maps. I neither can see another version of libxml2.so. ldd doesn't list libxml2.so as a nokogiri.so's dependency. objdump lists xmlReadMemory (and friends) as a nokogori.so's symbol (probably a sign that it was linked statically).

那么 nokogiri 如何访问 libxml2.so 的变量？这是否意味着加载 libxml2.so 会覆盖任何静态链接的版本？

So how come can nokogiri access libxml2.so's variables? Does that mean that loading libxml2.so overrides any statically linked versions? Can that happen in the middle of code execution?

推荐答案

那么nokogiri怎么能访问libxml2。那么变量是什么？

So how come can nokogiri access libxml2.so's variables?

这是设计使然（由于 nokogiri 的构建不正确。）

This is by design (and due to the fact that nokogiri was built incorrectly).

设计了UNIX共享库以模拟存档库。这意味着第一个导出给定符号的ELF图像获胜（与 -Bstatic 标志链接的库有一些复杂性，但我们现在将其忽略）。 / p>

UNIX shared libraries are designed to emulate archive libraries. This means that the first ELF image to export a given symbol wins (there are some complications for libraries linked with -Bstatic flag, but we'll ignore them for now).

这是否意味着加载libxml2.so会覆盖任何静态链接的版本？

Does that mean that loading libxml2.so overrides any statically linked versions?

是的，如果还导出了静态链接版本并且通过PLT对其进行了调用。

Yes, if statically linked version is also exported and calls to it go though PLT.

会发生这种情况吗？在代码执行过程中？

Can that happen in the middle of code execution?

具有惰性符号解析（默认设置，除非 LD_BIND_NOW 或 -z 生效），它将总是在代码执行过程中发生。

With lazy symbol resolution (which is default, except when LD_BIND_NOW or -z now are in effect) it will always happen in the middle of code execution.

现在，问题是如果 nokogiri 链接到 libxml.a ，它应该通过将该副本定位在自身内部而不隐藏其任何符号来隐藏该事实。这样可以防止最终用户不得不处理符号冲突。

Now, the problem is that if nokogiri links in a static copy of libxml.a, it should hide that fact by localizing that copy within itself and not exporting any of its symbols. That would prevent end users from having to deal with symbol conflicts.

您最好的选择是构建自己的 nokogiri 将其编译并链接到相同版本的libxml，或者与 nokogiri 维护人员联系，并要求他们修复其构建。

Your best bet is to either build your own nokogiri compiling and linking it against the same version of libxml, or to contact nokogiri maintainers and ask them to fix their builds.

这篇关于动态链接库可以覆盖静态库吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！