做电锯电音的网站,做内贸的什么网站效果好,定制公司网站,南京市城乡建设局网站文章目录 概述问题的产生基于mingw的DLL动态库基于mingw的EXE可执行程序Makefile文件中使用Qt库的\*.a文件mingw下的*.a 文件 和 *.dll 到底谁起作用小插曲 mingw 生成的 \*.a文件到底是什么为啥mingw的dll可用以编译链接过程转换为lib引导文件 概述
本文介绍了 QtCreator mi… 文章目录 概述问题的产生基于mingw的DLL动态库基于mingw的EXE可执行程序Makefile文件中使用Qt库的\*.a文件mingw下的*.a 文件 和 *.dll 到底谁起作用小插曲 mingw 生成的 \*.a文件到底是什么为啥mingw的dll可用以编译链接过程转换为lib引导文件 概述
本文介绍了 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 - qtTEMPLATE lib
DEFINES DLLOFMINGW_LIBRARYCONFIG c11Debug:DESTDIR $$PWD/../bin_d
Debug: TARGET dllofmingw_dRelease: DESTDIR $$PWD/../bin
Release: TARGET dllofmingwSOURCES \dllofmingw.cppHEADERS \dllofmingw.h \dllofmingw_global.hDEFINES 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.hclass DLLOFMINGW_EXPORT DllOfMingw
{
public:DllOfMingw();
public:std::string InvokeTest();
};
#endif // DLLOFMINGW_H//dllofmingw.cpp
#include dllofmingw.hDllOfMingw::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 - guiCONFIG c11 console
CONFIG - app_bundleDEFINES QT_DEPRECATED_WARNINGSSOURCES \main.cpp# youd better build a public include
INCLUDEPATH $$PWD/../DllOfMingwwin32 {Debug:LIBS -L$$PWD/../bin_d \-ldllofmingw_dRelease:LIBS -L$$PWD/../bin \-ldllofmingw
}# .exes dir same as .dll file
Debug:DESTDIR $$PWD/../bin_d
Release: DESTDIR $$PWD/../bin//mian.cpp
#include QCoreApplication
#include QDebug
#include dllofmingw.hint 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 CreatorMSVC编译器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_dRelease: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 c11TEMPLATE lib
CONFIG staticlibDEFINES QT_DEPRECATED_WARNINGSDebug:DESTDIR $$PWD/../bin_d
Debug: TARGET sllofmingw_dRelease: DESTDIR $$PWD/../bin
Release: TARGET sllofmingwSOURCES \sllofmingw.cpp
HEADERS \sllofmingw.h//sllofmingw.h
#ifndef SLLOFMINGW_H
#define SLLOFMINGW_H#include stringclass SllOfMingw
{
public:SllOfMingw();
public:std::string InvokeTest();
};#endif // SLLOFMINGW_H//sllofmingw.cpp
#include sllofmingw.hSllOfMingw::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.hint 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_ ? ? 0DllOfMingwQEAAXZ)该符号在函数 main 中被引用
//ExeOfVS.obj : error LNK2019 : 无法解析的外部符号 __declspec(dllimport) public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __cdecl DllOfMingw::InvokeTest(void) (__imp_ ? InvokeTestDllOfMingwQEAA?AV ? $basic_stringDU?$char_traitsDstdV?$allocatorD2stdXZ)该符号在函数 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我没时间继续该问题了只能暂时放弃。最后这小节与本文的主要目的契合度并不大如果以后有机会将单独开篇继续。
