在 Windows 下，当我在 MSVC 的 DLL 项目中编译 C/C++ 代码时，我得到 2 个文件：
MyDll.dllMyDll.lib据我了解，MyDll.lib 包含某种指针表，指示 dll 中的函数位置。当使用这个 dll 时，比如在一个 exe 文件中，MyDll.lib 在链接期间被嵌入到 exe 文件中，因此在运行时它“知道”函数在 MyDll.dll 中的位置并可以使用它们。
但如果我在 Linux 下编译相同的代码，我只会得到 一个 文件 MySo.so 而没有 MySo.a（相当于 Linux 中的 lib 文件）那么Linux下的可执行文件如果在链接过程中没有嵌入任何内容，如何知道函数在MySo.so中的位置？
【问题讨论】：
标签： c++ c linux windows shared-libraries
【讨论】：
在 Linux 上，链接器（不是动态链接器）搜索链接时指定的共享库，并在可执行文件中创建对它们的引用。当动态链接器加载这些可执行文件时，它会将它们所需的共享库加载到内存中并解析符号，从而允许运行二进制文件。
MySo.a，如果创建，实际上将包含要直接链接到二进制文件中的符号，而不是 Windows 上使用的“符号查找表”。
rustyx's answer 比我更彻底地解释了 Windows 上的过程；好久没用Windows了。
【讨论】：
您看到的差异更多的是实现细节 - 在 Linux 和 Windows 的底层工作方式类似 - 您的代码调用了一个静态链接到可执行文件中的存根函数，然后这个存根在必要时加载 DLL/shlib（在delayed loading 的情况，否则程序启动时会加载库）并且（在第一次调用时）通过 GetProcAddress/dlsym 解析符号。
唯一的区别是，在 Linux 上，这些存根函数（称为 PLT 存根）是在您将应用与动态库（库包含生成它们的足够信息）链接时动态生成的，而在 Windows 上，它们是在创建 DLL 本身时在单独的 .lib 文件中生成的。
这两种方法非常相似，实际上可以在 Linux 上模仿 Windows 导入库（参见 Implib.so 项目）。
【讨论】：
在 Linux 上，您将 MySo.so 传递给链接器，它能够仅提取链接阶段所需的内容，并在运行时添加 MySo.so 所需的引用。
【讨论】：
.dll 或 .so 是共享库（在运行时链接），而 .a 和 .lib 是静态库（在编译时链接）。这在 Windows 和 Linux 之间没有区别。
不同之处在于，它们是如何处理的。注意：区别仅在于海关，它们是如何使用的。以 Windows 的方式构建 Linux 并不太难，反之亦然，但实际上没有人这样做。
如果我们使用 dll，或者我们甚至从我们自己的二进制文件中调用一个函数，有一个简单明了的方法。例如，在 C 中，我们看到：
int example(int x) {
...do_something...
}
int ret = example(42);
但是，在 asm 级别上，可能存在许多差异。例如，在 x86 上，执行 call 操作码，并在堆栈上给出 42。或在某些寄存器中。或任何地方。没有人知道在编写 dll 之前，它将如何使用它。或者项目将如何使用它，可能是用现在甚至不存在的编译器（或用一种语言！）编写的（或者对于 dll 的开发人员来说是未知的）。
例如，默认情况下，C 和 Pascal 都从堆栈中放入参数（并获取返回值） - 但它们的执行顺序不同。您还可以通过一些依赖于编译器的优化在寄存器中的函数之间交换参数。
如你所见，Windows 的习惯是构建一个 dll，我们还用它创建了一个最小的.a/.lib。这个最小的静态库只是一个包装器，通过它可以访问该 dll 的符号（函数）。这会进行所需的 asm 级调用转换。
它的优点是兼容性。它的缺点是，如果你只有一个 .dll，你可能很难弄清楚它的函数是如何被调用的。这使得 dll 的使用成为一项黑客任务，如果 dll 的开发者没有给你.a。因此，它主要服务于封闭性目的，例如更容易为 SDK 获得额外的现金。
它的另一个缺点是即使使用动态库，也需要静态编译这个小包装器。
在 Linux 中，dll 的二进制接口是标准的并且遵循 C 约定。因此，不需要.a，并且共享库之间存在二进制兼容性，作为交换，我们没有微软自定义的优势。
【讨论】：