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

Question

有一个谜团，我想弄明白:

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

我有应用程序，我们称它为 APP，然后我有扩展名 EXT。 APP 扩展了一些在 EXT 中实现的功能，但 EXT 需要调用一些在 APP 中定义的功能才能“ Hook ”到它(例如在 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上却需要？为什么可以将 Linux 上的某些内容与未解析的外部符号链接(symbolic link)起来？它怎么知道我指的是哪个符号？它是否在 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 条目(并跳转到真实地址)。对同一函数的后续调用直接跳转到它。

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

我假设动态链接像其他 UNIX 类操作系统一样工作，它使用 ELF 格式。

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