C:使用MinGW-w64静态/动态链接的正确方法

Question

直觉：

• MinGW-w64是GNU编译器工具(GCC等)的Windows端口.
• 预编译的Windows二进制文件是.dll (动态链接)/ .lib (静态链接).
• 但是，MinGW-w64使用GNU编译器工具，因此需要.so / .a二进制文件。

我发现了什么：

• 根据红帽企业Linux文档的说法，MinGW/MinGW-w64/Cygwin链接器似乎在寻找S。
• 根据本教程，您应该动态地链接到.so，静态地链接到.a。
• 关于SO的一个问题表示您可以.lib，而在SO 说它不起作用上有另一个问题。

不幸的是，我无法从MinGW & MinGW-w64中找到明确的文档，说明在动态/静态链接库时什么是对的，什么是错的。

根据我的经验，我一直能够动态地链接到.dll，有一次，我能够静态地链接到.lib (使用-static标志)。

问题：

在使用MinGW-w64 GCC工具链编译时，.dll / .a二进制文件是否适合动态和静态链接库？换句话说，为MSVC生成的动态库和为GCC生成的静态库？

Answer 1

答案：

MinGW /MinGW-W64的能港

• 直接链接到.dll进行动态链接
• 间接链接到.dll.a进行动态链接(在编译时使用导入库)
• 链接到.as以进行静态链接。

.dll**?** 为什么MinGW /MinGW-W64的GCC连接器端口要寻找MinGW？

简而言之，最好的答案是因为.dll是微软在32位和64位操作系统上共享对象的答案。在Windows上，MinGW /MinGW-W64的端口使用Microsoft运行时(msvcrt.dll) [1]，因此它遵循Windows链接器规则。

动态链接库(或DLL)是Microsoft在Microsoft Windows和OS/2操作系统中实现共享库概念的工具。-- 从维基百科

因此，要动态链接库，您将使用文件扩展名：

1. .so用于Linux上的共享库，因为这是GCC二进制程序的链接器搜索的内容，
2. 或者是Windows上共享库的.dll，因为GCC的链接器的MinGW / MinGW-w64端口就是这样搜索的。

GCC的MinGW端口用于共享库对象的扩展在源代码中的cygming文件中显式列出。正如@ChronoKitsune所评论的，特别是：SHLIB_EXT = .dll in libgcc/config/i386/t-slibgcc-cygming。cygming文件(用于Cygwin和MinGW)对于MinGW、MinGW-w64以及Cygwin的32位和64位版本都是通用的.因此，GCC绑定到Windows的所有端口都是如此。

为什么.lib / MinGW-w64链接器会处理？

原则上，GCC的链接器不会将.lib识别为静态库。但是，链接器可能足够聪明，可以针对.lib导入的.lib进行链接(在.lib实际上是导入库的情况下)。例如，在库具有动态链接的依赖项的情况下，库将被动态链接(和将忽略“强制”静态链接的标志。)。

在这种情况下，我可以想象链接器不会抛出任何错误，而且看起来好像.lib实际上已经成功地链接了。

导入库是如何工作的？(免费)

在Windows上，.lib可以是两个库之一：

1. 编译器从.dll生成的一个导入库，其中包含编译期间的符号解析所需的所有定义(但是，函数实现除外) [2] 。
   1. 如果您尝试使用xxxx.dll /MinGW-W64的GCC二进制端口生成导入库，它将生成一个libxxxx.dll.a。扩展文件扩展名对于区分导入库和完全定义的静态库非常有用。使用MSVC编译时，此在扩展中，区别并不明显

​

1. 一个完全定义的静态库

.lib具有双重用途，因为正如@ChronoKitsune所述，MSVC链接器不直接与.dll链接。相反，在编译时需要导入库来解析符号定义，以便在运行时才加载.dll：

要链接的导入库(.LIB文件)。(链接器在构建DLL时创建导入库。) -- VS 2015文件

为什么MinGW/ MinGW-W64的GCC连接器端口要寻找.a**?** ？

这很简单-端口使用*-nix系统上使用的ar归档实用程序，@ChronoKitsune评论道：

静态库的扩展来自于包含在binutils中的ar (归档)程序。可以使用ar -t libxxx.a列出任何静态库中包含的对象文件。

这类似于MSVC的lib命令，如果lib /list foo.lib是静态库，则该命令将返回.obj文件的列表。