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

【问题标题】：Misunderstanding concerning g++, dynamic and static linking on linux vs windows关于 g++ 的误解，linux vs windows 上的动态和静态链接
【发布时间】：2011-07-25 04:44:24
【问题描述】：

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

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

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

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

对不起，如果这真的很分散，但我希望有人能帮助解决这个问题。非常感谢！

【问题讨论】：

Windows 上 boost 库的提示。至少在 Visual C++ 中，头文件具有告诉链接器要链接哪些库的编译指示，并且根本不需要 -l 选项。我猜 mingw 可能会有所不同。

标签： c++ g++ mingw dynamic-linking static-linking

【解决方案1】：

在 windows 上，或者至少是 windows 上的范例，您可以拥有一个 .lib（类似于 .a）和 .dll（类似于 .so，除了...不同），并且您必须在.lib 包含在运行时从 dll 调用函数的代码。它是否正确？

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

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

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

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

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

【讨论】：

您也可以将 .so 加载为插件 AFAIK。参见例如 Firefox 的 flashplugin.so。另请注意，从 4.4-4.5 版本开始，Windows 上的 GCC 如果导出所有符号，则可以直接链接到 DLL。

【解决方案2】：

这只是在编译时提供有关共享库的信息的两种方式。也许比较会更好地解释它？

在 Windows 中，它是：“您将使用共享库 (.dll)，这里（.a 或 .dll.a）是有关如何使用它的手册。”

在 Linux 中，它是：“您将使用共享库 (.so)，因此请事先查看 (.so)，以便您知道如何使用它。”

【讨论】：