概述

本文介绍了 QtCreator + mingW 集成开发环境下的动态库生成和使用方法，重点分析了mingw下动态库项目编译后生成的*.a文件的作用到底是什么。本文还对比分析了mingw下动态库的部署和使用与MSVC下动态库生成和使用方式上的不同。
使用MingW编译器时，没有生成.lib引导文件，那么mingW是如何完成动态库链接过程的呢？而且经验告诉我们，mingw下，可执行程序使用dll时，是可以直接指向dll文件进行编译链接过程的，它是怎么做到的呢？

关于VS集成开发环境下的DLL生成和部署使用，可参考《IDE/在VS下DLL动态库的部署和加载问题分析》，以更好对比分析。

MinGW 提供了一个开发环境，可以方便地在 Windows 平台上进行 C、C++ 和其他编程语言的开发。开发人员可以使用 MinGW 提供的工具和库来编写 Windows 应用程序，而不需要依赖于 Microsoft Visual Studio 或其他商业开发工具。MinGW 是基于 GNU 工具集的一个分支，它允许开发人员在 Windows 环境中使用类似于 Linux 下的开发工具，如 GCC 编译器、GNU Make 等，以及一些常用的库文件，如 C/C++ 运行时库、Windows API 的头文件等。

问题的产生

Demo 代码 的总体目录分布，E:\TestDll，下设：bin、bin_d、DllOfMingw、ExeOfMingw 目录，DllOfMingw.pro 位于DllOfMingw目录；ExeOfMingw.pro 位于 ExeOfMingw 目录。特殊测试步骤上，还设 E:\TestDll\lib 目录。

基于mingw的DLL动态库

在 Qt Creator 文件菜单下，选择新建文件或项目，在弹出的选项卡中，选择 Library - C++ Library，新建名为 DllOfMingw 的工程。

Qt modules 选择 Qt 无关，Kits 选择 Mingw 64…

//DllOfMingw.pro 
CONFIG -= qt

TEMPLATE = lib
DEFINES += DLLOFMINGW_LIBRARY

CONFIG += c++11

Debug:DESTDIR = $$PWD/../bin_d
Debug: TARGET = dllofmingw_d

Release: DESTDIR = $$PWD/../bin
Release: TARGET = dllofmingw

SOURCES += \
    dllofmingw.cpp

HEADERS += \
    dllofmingw.h \
    dllofmingw_global.h

DEFINES += QT_DEPRECATED_WARNINGS

//dllofmingw_global.h
#ifndef DLLOFMINGW_GLOBAL_H
#define DLLOFMINGW_GLOBAL_H

#if defined(_MSC_VER) || defined(WIN64) || defined(_WIN64) || defined(__WIN64__) || defined(WIN32) || defined(_WIN32) || defined(__WIN32__) || defined(__NT__)
#  define Q_DECL_EXPORT __declspec(dllexport)
#  define Q_DECL_IMPORT __declspec(dllimport)
#else
#  define Q_DECL_EXPORT     __attribute__((visibility("default")))
#  define Q_DECL_IMPORT     __attribute__((visibility("default")))
#endif

#if defined(DLLOFMINGW_LIBRARY)
#  define DLLOFMINGW_EXPORT Q_DECL_EXPORT
#else
#  define DLLOFMINGW_EXPORT Q_DECL_IMPORT
#endif

#endif // DLLOFMINGW_GLOBAL_H

//dllofmingw.h
#ifndef DLLOFMINGW_H
#define DLLOFMINGW_H
#include <string>
#include "dllofmingw_global.h"

class DLLOFMINGW_EXPORT DllOfMingw
{
public:
    DllOfMingw();
public:
    std::string InvokeTest();
};
#endif // DLLOFMINGW_H

//dllofmingw.cpp
#include "dllofmingw.h"

DllOfMingw::DllOfMingw() { }

std::stringDllOfMingw::InvokeTest()
{ return "Dll Interface was invoked!"; }

以Debug模式编译上述项目，在E:\TestDll\bin_d目录下生成两个文件，

它们是干什么的，尤其是 libdllofmingw_d.a 到底是干什么的，容后再叙。

基于mingw的EXE可执行程序

在 Qt Creator 文件菜单下，选择新建文件或项目，在弹出的选项卡中，选择 Application，新建名为 ExeOfMingw 的Qt控制台工程。选择与DLL项目相同的Kits设置。项目创建与DLL一致，均为 E:\TestDll 目录。

//ExeOfMingw.pro
QT -= gui

CONFIG += c++11 console
CONFIG -= app_bundle

DEFINES += QT_DEPRECATED_WARNINGS

SOURCES += \
        main.cpp

# you'd better build a public include
INCLUDEPATH += $$PWD/../DllOfMingw

win32 {
    Debug:LIBS  +=   -L$$PWD/../bin_d \
                     -ldllofmingw_d

    Release:LIBS  += -L$$PWD/../bin \
                      -ldllofmingw
}

# .exe's dir same as .dll file
Debug:DESTDIR = $$PWD/../bin_d
Release: DESTDIR = $$PWD/../bin

//mian.cpp
#include <QCoreApplication>
#include <QDebug>
#include "dllofmingw.h"

int main(int argc, char *argv[])
{
    QCoreApplication a(argc, argv);

    DllOfMingw aDll;
    qDebug() << QString::fromLocal8Bit(aDll.InvokeTest().c_str());

    return a.exec();
}

Makefile文件中使用Qt库的*.a文件

在上述测试代码下，DLL和EXE均可正常编译和执行。运行可输出 “Dll Interface was invoked!”…

之前在整理其他集成开发环境相关问题的时候就发现过，在Makefile文件中，LIBS中对Qt库的引用使用的是*.a文件，当时只作了记录并未细究。以上述正常编译和运行的代码为例子，打开ExeOfMingw 项目编译目录下的 Makefile.Debug 文件，

LIBS = -LE:\TestDll\bin_d -ldllofmingw_d D:\Qt\Qt5.12.8\5.12.8\mingw73_64\lib\libQt5Cored.a  

此时的相关的编译输出，截图如下，可以与makefile相互匹配上，

可惜的是，我们无法通过红色框标记的内容，来判断出 ExeOfMingw 在编译阶段，到底使用了 dllofmingw_d.dll 和 libdllofmingw_d.a 的哪一个。不过，看到 ExeOfMingw 在LIBS中引用的是libQt5Cored.a 文件，我们大概率先猜测，“-LE:\TestDll\bin_d -ldllofmingw_d” 会指向 $$PWD/…/bin_d/libdllofmingw_d.a 文件，但事实如此吗？

mingw下的*.a 文件 和 *.dll 到底谁起作用

单纯地结合VS下动态库部署和执行的相关理论常识，DLL它也不应该与编译有关才对！但是以往的经验早就告诉了我们，在mingw编译套件下，dll文件似乎是在编译过程中起到作用的。为此，我们将在上述正常编译和运行的程序部署的基础上，逐步展开测试。注意，为了保证测试的可靠性，我每次重新编译前，均是手动删除上次编译生成的过程文件。

Test-1
我们重点关注 libdllofmingw_d.a 这个文件，并猜测它可能与 MSVC编译器下的动态库引导文件起到了相同的作用。为此，我们删除 E:\TestDll\bin_d\libdllofmingw_d.a 文件，重新执行 ExeOfMingw 编译，并无编译异常发生，运行也无误。
Test-2
然后我们将 libdllofmingw_d.a 恢复回来，将 dllofmingw_d.dll 删除，再次重新执行 ExeOfMingw 编译，也不存在编译异常。dll是运行时加载使用的，没有它，程序肯定是无法正常运行的。
Test-3
我们在 《IDE/集成开发环境 Qt Creator+MSVC编译器+CDB调试器》文中，已经测试过，在使用MSVC编译器的情况下，pro工程文件中的LIBS必须配置动态库引导文件lib的路径和名称，否则无法通过编译。前文中的测试，我们每次只是删除了 dllofmingw_d.dll 或 libdllofmingw_d.a 中的一个，如果两个一起删除呢？

呢，编译报错了，找不到指定的 dllofmingw_d 库了。而且此处的含义应该是：即没有找到 dllofmingw_d.dll ，也没有找到 libdllofmingw_d.a 文件。因为，但凡他俩存在一个，都没有出现编译错误。
再来一轮回归测试，
只将 dllofmingw_d.dll 添加回到 E:\TestDll\bin_d，编译 ExeOfMingw 无误，运行无误。
只将 libdllofmingw_d.a 添加回到 E:\TestDll\bin_d，编译 ExeOfMingw 无误，但程序无法正常运行。
Test-4
来点狠的，使用migw编译器时，我若不进行 LIBS配置，

临时结论，
引用 mingw编译的DLL时，也必须要配置 LIBS 路径和文件，但是对于编译过程，只要存在 dllofmingw_d.dll 或 libdllofmingw_d.a 中的其中任意一个，即可通过编译过程。因此可以猜测？mingw编译动态库项目时生成的 *.lib文件 和 *.a 文件，都可以在编译环节支持链接到调用它的可执行程序中。

验证 *.a文件对编译过程的支持，
进一步的，我们将 *.a 脱离 bin文件夹，放到单独的E:\TestDll\lib文件夹下，dllofmingw_d.dll依然放在E:\TestDll\bin_d下，相应的修改 ExeOfMingw.pro 文件中的 LIBS 配置，

win32 {
    Debug:LIBS  +=   -L$$PWD/../lib \
                     -ldllofmingw_d

    Release:LIBS  += -L$$PWD/../lib \
                      -ldllofmingw
}

经过测试，可以通过编译过程，运行也没有任何异常。

最后的几个结论，

• mingw下的动态库引用，也是必须要进行LIBS配置的。
• mingw下编译动态库项目时生成的 lib*.a文件，可以用以编译链接过程。
• 且qmke构建的项目中，对Qt框架库的引用，LIBS配置的就是 *.a类型的文件。
• 如果没有 *.a文件，只有mingw下生成的.dll文件，也是能支持编译链接过程的。

如此看来，针对动态库项目，把mingw下的*.a文件类比为MSVC下的*.lib引导文件，并没有什么大问题，它们的命名方式和功能都基本一致。差别较大的地方在于，mingw下的.dll类型的文件，自身也可以参与编译链接过程，而msvc下生成的.dll文件并没有此功能。

小插曲

在某个测试阶段，我遇到了如下运行异常。编译没有问题，但是程序总是无法启动，连main函数都进不去。

尝试，重新启动QtCreator 并未生效。“qtcreator_process_stub.exe” 是 Qt Creator 中用于与正在调试的应用程序进行交互的帮助进程。它允许 Qt Creator 与应用程序进行通信，设置断点，检查变量并控制调试过程。如上错误消息，“qtcreator_process_stub.exe” 进程无法启动，但返回 “操作成功完成”，意味着进程的执行本身并没有发生错误，操作系统返回的进程退出代码是 “0”，代表进程正常退出。

我将，dllofmingw_d.dll 和 ExeOfMingw.exe 拷贝到Qt对应的bin库下执行，没有问题。我关机重启了PC，依然无济于事。于是，我将关于动态库的引用全部注释掉，也无济于事。我随便新建一个新的控制台应用程序，测试我的IDE环境有没有问题? 结果悲催了，不能用了竟然。难道，我的IDE被Qt公司使绊子啦？
使用 Everything 搜索 qtcreator_process_stub 找到它，D:\Qt\Qt5.9.3\Tools\QtCreator\bin，并使用命令窗口执行它，

结合此情此景，我还能想到的可能是，杀毒软件，打开，果然，从隔离区将上述文件恢复后，相关问题不攻自破。

mingw 生成的 *.a文件到底是什么

在VS & MSVC下当我们使用 动态库隐式加载方式时，必须要有 *.lib的动态引导文件，才可以正常编译。在mingw下没有 *.lib文件生成， *.a 文件看上去倒是有点类似 MSVC下的 *.lib，但此时我还不确定 *.a文件到底是啥 ？有的资料中显示， *.a 文件是静态库文件，但我觉得这就跟有人胡说MSVC下的 *.lib文件是静态库文件一样。

为进一步说明，mingw下的 *.a 文件不是静态库文件，我们新建一个mingw下的静态库项目，将其实现成DLL一致，并对比它们。

在 Qt Creator 文件菜单下，选择新建文件或项目，在弹出的选项卡中，选择 Library - C++ Library，项目名称 SllOfMingw，创建路径为E:\TestDll，与DLL项目一致。选择项目类型为 Statically Linked Library 静态链接库。Qt module 还是none，与Qt无关，Kits也还选择mingw 64… 将 SllOfMingw 类与 DllOfMingw 类 做一致的实现…

观察静态库项目，发现，其没有了DLL项目下的 dllofmingw_global.h 这样的导出宏定义；pro文件相比DLL，其中多出来一个 CONFIG += staticlib 配置。为了具有更好的可比性，我们将SLL和DLL实现为一样的接口和属性。

//SllOfMingw.pro
CONFIG -= qt
CONFIG += c++11

TEMPLATE = lib
CONFIG += staticlib

DEFINES += QT_DEPRECATED_WARNINGS

Debug:DESTDIR = $$PWD/../bin_d
Debug: TARGET = sllofmingw_d

Release: DESTDIR = $$PWD/../bin
Release: TARGET = sllofmingw

SOURCES += \
    sllofmingw.cpp
HEADERS += \
    sllofmingw.h

//sllofmingw.h
#ifndef SLLOFMINGW_H
#define SLLOFMINGW_H

#include <string>

class SllOfMingw
{
public:
    SllOfMingw();
public:
    std::string InvokeTest();
};

#endif // SLLOFMINGW_H

//sllofmingw.cpp
#include "sllofmingw.h"

SllOfMingw::SllOfMingw() { }

std::string SllOfMingw::InvokeTest() {
    return "Sll Interface was invoked!"; }

编译完成后可知，该静态库项目仅仅生成了名为 libsllofmingw_d.a 的静态库文件，如下红框标记。

另外，
我们也注意到，虽然都是.a静态库文件类型的后缀，但是 libsllofmingw_d.a 真静态库文件比 libdllofmingw_d.a 这假静态库文件要大一个数量级。因此可断定，libdllofmingw_d.a 不是真正的静态库文件，这与MSVC下编译生成的*.lib文件不是真正的静态库文件如出一辙。与MSVC下的.lib引导文件一样，mingw动态库项目生成的.a类型的文件，也具有参与编译链接过程的能力，顾，完全也可以称此时的.a文件为mingw下的动态库引导文件。

为啥mingw的dll可用以编译链接过程

先给自己广普下编译器的链接过程，
编译器的连接过程是将多个编译后的目标文件（通常是 .obj 文件）和库文件（静态库或动态库）合并成最终的可执行文件或共享库的过程。连接器Linker的连接过程通常分为以下几个步骤：
符号解析（Symbol Resolution）：连接器首先需要解析目标文件中的符号引用。符号引用是指在一个目标文件中引用了另一个目标文件或库文件中定义的函数、变量等符号。
地址重定位（Address Relocation）：解析完符号引用后，连接器需要对引用进行地址重定位。这是因为目标文件中的符号地址是相对于目标文件自身的，连接器需要根据目标文件在最终可执行文件或共享库中的位置，对这些地址进行修正。
合并目标文件：连接器将所有的目标文件和库文件合并成一个单一的可执行文件或共享库。这一步通常包括解决符号冲突，以及将所有目标文件和库文件中的代码和数据按照一定的规则组织在一起。
生成可执行文件或共享库：连接器将合并后的目标文件和库文件生成最终的可执行文件或共享库。在生成可执行文件时，连接器会为程序的入口点设置正确的入口地址，使得程序能够正确地开始执行。

一种特殊的动态链接DLL的方法，
Mingw使用DLL本身作为动态库的引导文件，主要是因为它采用了一种称为"Load-Time Dynamic Linking"的链接方式。这是一种在程序加载时动态链接DLL的方法。当程序启动时，Mingw会解析DLL文件的导出表，并将DLL中的符号地址与程序中的对应符号进行绑定。这样，在程序运行过程中，当需要调用DLL中的函数或使用DLL中的数据时，程序就可以直接通过绑定的地址进行调用，而无需再进行动态链接。
这种链接方式的优势是在程序启动时就已经完成了所有的动态链接操作，因此在运行时可以更快地调用DLL中的函数，避免了运行时的动态链接开销。另外，由于Mingw是一个开源的编译器，它不像MSVC那样受到特定的商业约束和限制。因此，Mingw可以更灵活地处理动态链接的方式，选择将DLL本身作为动态库的引导文件。这种方式在一定程度上简化了编译和链接过程，使得Mingw可以更方便地与开源的DLL库进行集成和使用。

转换为lib引导文件

通常情况下，Mingw生成的DLL可以用于编译链接过程是因为它使用了与MSVC兼容的运行时库，可以与MSVC编译的可执行文件进行链接。而MSVC生成的DLL由于使用了自己的运行时库，所以不能直接与Mingw编译的可执行文件进行链接。如果需要在MSVC编译的项目中使用Mingw生成的DLL，需要进行一些额外的配置和适配工作。
但也要注意，使用 MinGW 编译生成的 DLL 文件通常依赖于 MinGW 的运行时库（例如 mingw32.dll），这些库在没有 MinGW 的系统上可能不存在或不兼容。因此需要确保将这些依赖性包含在生成的 DLL 文件中。这种跨编译器的装换并不是一件简单的事情，不到万不得已，是不建议如此操作的。

接下来我们将尝试将 DllOfMingw 项目生成的DLL转换成可以在mscv下使用的库…

在 D:\Qt\Qt5.12.8\Tools\mingw730_64\bin 下找到 gendef.exe 工具，该工具从 DLL 文件生成 .def 文件。

成功生成到了，D:\Qt\Qt5.12.8\Tools\mingw730_64\bin\dllofmingw_d.def，哈哈，肯定还有其他指令参数，没再细究。直接剪切dllofmingw_d.def到我的项目文件目录E:\TestDll\bin_d，进行下一步，
打开 Visual Studio 开发人员命令提示符，使用 lib 命令来生成 .lib 文件。命令如下，

如上，同时生成了.lib和.exp两种文件，

接下来我们新建一个VS项目，动态库部署和代码都没有问题，但是，我并没有成功。编译报错，

#include <stdio.h>
#include "dllofmingw.h"

int main()
{
    DllOfMingw aDll;
    printf("%s", aDll.InvokeTest().c_str());

    system("pause");
    return 0;
}

//ExeOfVS.obj : error LNK2019 : 无法解析的外部符号 "__declspec(dllimport) public: __cdecl DllOfMingw::DllOfMingw(void)" (__imp_ ? ? 0DllOfMingw@@QEAA@XZ)，该符号在函数 main 中被引用
//ExeOfVS.obj : error LNK2019 : 无法解析的外部符号 "__declspec(dllimport) public: class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl DllOfMingw::InvokeTest(void)" (__imp_ ? InvokeTest@DllOfMingw@@QEAA?AV ? $basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)，该符号在函数 main 中被引用
//..\bin_d\ExeOfVS.exe : fatal error LNK1120 : 2 个无法解析的外部命令

通过上述告警信息，我发现，其中提示的导出符号，与dllofmingw_d.def中的定义，并不一致，

//dllofmingw_d.def
;
; Definition file of dllofmingw_d.dll
; Automatic generated by gendef
; written by Kai Tietz 2008
;
LIBRARY "dllofmingw_d.dll"
EXPORTS
_ZN10DllOfMingw10InvokeTestB5cxx11Ev
_ZN10DllOfMingwC1Ev
_ZN10DllOfMingwC2Ev

我没时间继续该问题了，只能暂时放弃。最后这小节，与本文的主要目的，契合度并不大，如果以后有机会将单独开篇继续。