linux如何为用作扩展的库解析未解析的符号

Question

我想了解一个谜团：

我制作了一个可以使用动态库扩展的应用程序，其中包含一些代码，但需要访问应用程序本身中定义的一些函数。说清楚：

我有应用程序，我们称它为 APP，然后我有扩展名 EXT。 APP 扩展了一些在 EXT 中实现的功能，但 EXT 需要调用 APP 中定义的一些函数才能“挂钩”到它（例如在 APP 布局中注册新项目等）。在 MS Windows 中，由于未解析的符号，我将无法编译 EXT - 这是有道理的 - 我将如何调用 APP 中的函数而实际上没有任何东西可以链接它们，所以我创建了一个 APP 的 dll 库，它基本上是APP 只是构建为一个 DLL，其中包含我需要访问的所有这些函数，这些函数使用 __declspec(dllexport) 导出（我们称之为 LIB），所以它的工作方式如下：

APP加载EXT，EXT通过LIB调用APP函数。在某些时候这是一个令人讨厌的解决方案，但我想不出更好的解决方案。最重要的是——它完美无缺。

现在让我抓狂的是，为什么这一切都可以在 linux 上运行而无需创建 LIB？这个 windows 的东西很讨厌，但它很有意义，但是在 linux 上我可以构建 EXT，即使不必构建 APP 或 LIB，它只是以某种方式忽略这些未解析的符号并无论如何链接它。整个库都包含它们，我可以通过调用来验证：

ld: warning: cannot find entry symbol _start; not setting start address
libhuggle_md.so: undefined reference to `Huggle::Query::NetworkManager'
libhuggle_md.so: undefined reference to `Huggle::Syslog::HuggleLogs'
libhuggle_md.so: undefined reference to `Huggle::Core::HuggleCore'
libhuggle_md.so: undefined reference to `Huggle::QueryPool::HugglePool'
libhuggle_md.so: undefined reference to `Huggle::Localizations::HuggleLocalizations'
libhuggle_md.so: undefined reference to `Huggle::Configuration::HuggleConfiguration'
libhuggle_md.so: undefined reference to `Huggle::GC::gc'
libhuggle_md.so: undefined reference to `Huggle::WikiUser::WikiUser(QString)'
libhuggle_md.so: undefined reference to `Huggle::WikiUtil::MessageUser(Huggle::WikiUser*, QString, QString, QString, bool, Huggle::Query*, bool, bool, bool, QString, bool, bool)'

因此您可以看到 EXT 引用了 APP 的某些功能，但它从未链接到任何可以实现它们的库。他们只是没有解决。

当我在 APP 中加载 EXT 时，内核内部会发生一些神奇的事情，并且会神奇地工作。为什么linux上的APP不需要LIB，而windows需要LIB？为什么可以将 linux 上的某些内容与未解析的外部符号链接？它怎么知道我指的是哪些符号？它是否在 APP 中找到它们并在运行时解析它们？

对于任何感兴趣的人，这里有一个完整的来源：https://github.com/huggle/huggle3-qt-lx 如果你在 linux 上克隆它并运行 ./configure --extension 然后让你会看到它首先构建一个扩展（即使没有任何链接）然后它会创建应用程序，如果您运行 make install 然后尝试运行它，您会看到它加载得很好，并使用一些魔法在运行时修复了库中未解析的符号。这是如何运作的？为什么它在 Windows 中不起作用？

Answer 1

我认为这与用于 linux（以及许多其他 *NIX）中的可执行文件和库的 ELF 格式以及动态链接器有关。

当动态链接程序启动时（它的进程被创建），动态链接器准备这个进程的地址空间。 Linux 库是使用 PIC（位置无关代码）编译的，因此它们可以放置在进程地址空间中的任何位置。运行时来自不同模块的函数之间的链接通过 PLT（过程查找）和 GOT（全局偏移）表解决。 PLT（只读，可执行部分）将间接跳转指令保存到 GOT（读写，不可执行部分）表中的地址。第一次通过 PLT 调用函数会跳转到一些运行时链接器函数，该函数会更新 GOT 条目（并跳转到实际地址）。对同一个函数的后续调用直接跳转到它。

据我了解，编译器有足够的信息（函数原型和头文件中的其他数据）来正确构建库。但是要构建可执行文件，您必须提供所有必需的库（但在运行时您可以更改使用的库，只要它们提供所有使用的功能）。

我假设动态链接的工作方式与使用 ELF 格式的其他 UNIX 等操作系统类似。

我对 Windows 可执行格式不是很熟悉，所以我无法评论为什么类似的技巧在那里不起作用。