c++ - 关于g++的误解，linux vs windows上的动态和静态链接

Question

我对今天学到的东西有点困惑。我希望有人能帮助我。

我理解动态链接和静态链接的概念，但是问题如下。在 Windows 上，或者至少在 Windows 上的范例中，你可以有一个 .lib(类似于 .a)和 .dll(类似于 .so，除了......不同)并且你必须在 .lib 中静态链接包含在运行时从 dll 调用函数的代码。这样对吗？换句话说，gcc 或 g++ 必须在编译/链接时有可用的 .lib 文件，并且能够在运行时找到 .dll 文件。请更正此处的任何错误假设。

但是，我将我的小应用程序中的一些源文件分开，因为我想让它们成为一个库。当我使用 -shared 选项在我的目标文件上运行 g++ 时，这基本上会创建一个共享库 (.so)？这就是困惑产生的地方。在链接时和运行时都需要相同 so 文件？我无法理解链接时在 -L/-l 选项中如何需要它，但在运行时它仍然需要该文件。这真的是常态吗？ dll 有根本的不同吗？

最后，最后一个问题。在 Windows 上使用类似 boost 的库。我按照说明构建了boost。最后，stage/lib 目录包含重复序列为 name.a、name.dll.a、name.dll 的库。这个计划的目的是什么？我知道我在运行时需要 dll 文件，但是当我在链接时使用 -L/-l 选项时，那么它使用的是什么文件？

抱歉，如果这真的很零散，但我希望有人能帮助解决这个问题。非常感谢!

Answer 1

On windows, or at least the paradigm on windows, you can have a .lib (which is like .a) and .dll (which is like .so, except... different) and you must statically link in the .lib which contains code that calls functions from the dll at runtime. Is this correct?

是也不是。这是 DLL 在 Windows 上工作的一种方式，但这不是唯一的方式。

您可以使用 Win32 API 调用手动加载 DLL。但如果这样做，则必须手动获取函数指针才能实际访问 DLL。导入库(您正在谈论的静态库)的目的是自动执行此操作。

手动执行此操作的好处是您可以挑选所需的 DLL。这就是一些应用程序提供插件支持的方式。用户编写一个导出一组定义良好的 API 函数的 DLL。您的程序从一个目录加载它们，并将每个 DLL 的函数指针捆绑到它自己的对象中，该对象表示该插件的接口(interface)。

GCC 的工作方式相同，在 Windows 上。构建 DLL 会生成一个 DLL 和一个导入库。由于编译器的原因，它是一个“.a”文件而不是“.lib”，但它仍然做同样的事情。

在 Linux 上，.so 文件是 .dll 和导入库的组合。因此，在编译有问题的程序时链接到 .so，它的作用与链接到导入库的作用相同。