尧图网页设计 
简介MinGW-i686 是一套面向 Windows 平台的开源开发工具集专为 i686 架构传统 32 位 x86 处理器打造适合习惯 Linux 命令行开发环境、又需要在 Windows 上构建原生 32 位程序的开发者与学习者。包内集成 GCC 多语言编译器、GDB 调试器、Make 自动化构建工具、Binutils 二进制处理工具及 MSYS 类 Unix 环境覆盖编译、链接、调试与项目构建全流程。资源共约 2000 个文件以 h 头文件1207 个、hpp266 个、a 静态库219 个为主另有 exe 可执行程序、tcc、log 日志及 idl、dlg 等类型压缩包约 47.26MB目录结构完整便于按模块查阅与配置。目前已有 712 人学习下载。解压后可将 bin 目录加入系统 PATH 环境变量即可在命令提示符或 PowerShell 中直接调用工具链readme.txt 提供安装与使用说明mingw64 目录还附带 64 位工具链方便处理不同架构需求是 Windows 下开发 32 位应用的实用工具集。1. MinGW-i686 开发工具集32 位 Windows 原生编译链的最后一公里如果你还在维护一套十年前的 C/C 工程或者要给老旧的工业控制软件打补丁大概率会遇到一个绕不开的问题目标机器是 32 位 Windows而手头只有 64 位的 MSVC 工具链。这时候 MinGW-i686 就成了少数能救场的方案。它本质上是把 GCC 工具链移植到 Windows 平台的一套开发工具集i686 这个后缀明确指向 32 位 x86 架构生成的是不依赖第三方运行库的原生 PE 文件。和 MSVC 最大的区别在于MinGW 走的是 GNU 那套工具链习惯Makefile、CMake、Autotools 基本可以原样搬过来不需要为了迁就 cl.exe 去改构建脚本。这套资源适合三类人需要维护 32 位遗留项目的工程师、想用 GCC 但不想装完整 Cygwin 的开发者、以及教学场景里需要统一工具链的环境。下面从工具集的实际构成开始拆把安装、配置、踩坑和验证一条线走完。2. MinGW-i686 工具集拆解从 bin 目录到链接器参数2.1 工具集里到底装了些什么拿到 MinGW-i686 的包之后第一件事是搞清楚目录结构。典型的安装根目录下会有 bin、include、lib、libexec、share 这几个文件夹。bin 目录是核心里面放着 gcc.exe、g.exe、gfortran.exe、windres.exe、mingw32-make.exe、ar.exe、ld.exe、objdump.exe、gdb.exe 这些可执行文件。include 放的是 C 和 C 标准库以及 Windows API 的头文件lib 里是静态库和导入库libexec 里是 gcc 内部调用的子程序share 里是文档和本地化信息。这里有个容易混淆的点MinGW 和 MinGW-w64 不是一回事。MinGW 原版项目在 2013 年左右基本停更了对 C11 之后的标准支持有限而 MinGW-w64 是社区 fork 出来继续维护的版本同时支持 32 位和 64 位目标。你拿到的这个 i686 包如果是较新的构建底层很可能是 MinGW-w64 的 32 位目标版本只是沿用了 MinGW 的叫法。判断方法很简单在命令行里跑gcc -v看输出里的 Target 字段是不是i686-w64-mingw32如果是那就是 MinGW-w64 的 32 位构建。工具集里几个关键组件的职责需要分清楚。gcc 是编译器驱动负责调用预处理器、编译器、汇编器和链接器g 是 C 前端windres 用来编译 Windows 资源文件.rc生成 .o 或 .resmingw32-make 是 GNU Make 的 Windows 移植版和 Linux 下的 make 用法一致只是文件名不同以免和系统里其他 make 冲突gdb 是调试器配合 gcc 的 -g 选项使用。2.2 环境变量配置与多版本共存安装完成后把 MinGW-i686 的 bin 目录加到系统 PATH 里是最直接的做法。但如果你机器上同时有 MSVC、Cygwin、MinGW-w64 64 位版本直接改系统 PATH 会引发工具链冲突。更稳妥的方式是用一个批处理脚本临时设置环境只在当前会话生效。echo off REM 保存当前 PATH避免污染全局环境 set OLD_PATH%PATH% set MINGW32_HOMED:\tools\mingw32 set PATH%MINGW32_HOME%\bin;%PATH% REM 验证工具链指向正确 where gcc gcc -dumpmachine REM 在这里执行编译命令 REM mingw32-make -f Makefile.mingw REM 恢复 PATH set PATH%OLD_PATH%这段脚本的逻辑是先把原始 PATH 存到 OLD_PATH然后把 MinGW-i686 的 bin 目录插到最前面这样 where gcc 找到的就是 32 位版本。gcc -dumpmachine会输出目标三元组i686 开头的才是我们要的。编译完成后恢复 PATH不影响其他会话。参数方面MINGW32_HOME 换成你自己的安装路径注意路径里不要有空格和中文否则 windres 处理资源文件时可能报错。如果你用 CMake 构建项目还需要在 CMakeLists.txt 或命令行里指定编译器。常见做法是写一个 toolchain 文件# mingw32-toolchain.cmake set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86) set(CMAKE_C_COMPILER D:/tools/mingw32/bin/gcc.exe) set(CMAKE_CXX_COMPILER D:/tools/mingw32/bin/g.exe) set(CMAKE_RC_COMPILER D:/tools/mingw32/bin/windres.exe) set(CMAKE_FIND_ROOT_PATH D:/tools/mingw32) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)配置时用cmake -DCMAKE_TOOLCHAIN_FILEmingw32-toolchain.cmake ..来生成构建系统。CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 设为 NEVER 是为了让 CMake 在宿主机上找构建工具而库和头文件只在 MinGW 目录下找避免误用系统里的其他版本。2.3 编译链接参数与运行时依赖MinGW-i686 默认生成的是动态链接到 msvcrt.dll 的可执行文件。msvcrt.dll 是 Windows 系统自带的 C 运行库从 Windows 2000 开始就存在所以生成的 exe 在绝大多数 Windows 机器上可以直接跑不需要额外带 DLL。但如果你用了 C 标准库的某些特性可能需要静态链接 libstdc 和 libgcc。g -O2 -m32 main.cpp utils.cpp -o app.exe ^ -static-libgcc -static-libstdc ^ -Wl,-Bstatic -lstdc -Wl,-Bdynamic这里-m32明确指定生成 32 位代码虽然工具链本身已经是 i686 目标但加上这个参数可以防止误用 64 位选项。-static-libgcc和-static-libstdc把 GCC 的运行库静态链进去减少对 libgcc_s_dw2-1.dll 和 libstdc-6.dll 的依赖。-Wl,-Bstatic和-Wl,-Bdynamic是传给链接器的选项控制后续库的链接方式。注意顺序静态库要放在动态库前面。如果你需要生成不依赖 msvcrt.dll 的完全静态版本可以加-static选项但这会把整个运行库都链进去生成的 exe 体积会明显增大。常见做法是先用-static-libgcc -static-libstdc减小依赖再用 Dependency Walker 或objdump -p app.exe | findstr DLL Name检查还缺哪些 DLL。3. 从源码到 exeMinGW-i686 编译流程实操3.1 一个最小 C 工程的完整构建先从一个最简单的 C 程序开始把整个流程跑通。新建一个 hello.c#include stdio.h #include windows.h int main(void) { // 调用 Windows API 获取系统目录验证链接是否正常 char buf[MAX_PATH]; GetSystemDirectoryA(buf, MAX_PATH); printf(Hello from MinGW-i686\n); printf(System dir: %s\n, buf); return 0; }编译命令gcc -O2 -Wall -m32 hello.c -o hello.exe -luser32-O2开优化-Wall开常用警告-m32指定 32 位目标-luser32链接 user32 库因为用到了 GetSystemDirectoryA。编译完成后用objdump -f hello.exe查看文件格式输出里 architecture 应该是 i386format 是 pei-i386。再用file hello.exe确认如果显示 PE32 executable (console) Intel 80386说明生成正确。如果编译时报undefined reference to GetSystemDirectoryA说明没链接 user32。MinGW 的链接器不会自动链接所有系统库用到哪个 API 就要显式加对应的 -l 参数。常见的库映射关系kernel32、user32、gdi32、advapi32、shell32、ole32、comctl32。不确定某个函数在哪个库时可以用grep -r FunctionName /path/to/mingw/include先找头文件再根据头文件里的 pragma comment 或文档确定库名。3.2 Makefile 与 mingw32-make 的配合手工敲编译命令只适合验证实际项目还是要用 Makefile。MinGW 自带的 mingw32-make 和 GNU Make 语法完全兼容但有几个 Windows 特有的注意点。CC gcc CXX g CFLAGS -O2 -Wall -m32 -DWIN32 -D_WINDOWS CXXFLAGS $(CFLAGS) -stdc11 LDFLAGS -m32 -static-libgcc -static-libstdc LIBS -luser32 -lkernel32 -lgdi32 SRCS main.c utils.c OBJS $(SRCS:.c.o) TARGET app.exe all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ $(LIBS) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: del /Q *.o *.exe 2nul .PHONY: all clean这个 Makefile 里del /Q是 Windows 命令2nul把错误输出重定向到空设备避免文件不存在时报错。-DWIN32 -D_WINDOWS是预定义宏很多跨平台代码靠这些宏判断当前平台。$(SRCS:.c.o)是 Make 的替换引用把 .c 后缀换成 .o。执行时用mingw32-make -j4并行编译-j4表示同时跑 4 个任务具体数字按 CPU 核心数调整。有个坑要注意Makefile 里的缩进必须用 Tab不能用空格。很多编辑器默认把 Tab 转成空格导致missing separator错误。在 VSCode 里可以设置editor.insertSpaces: false针对 Makefile 文件或者用.editorconfig统一管理。3.3 资源文件编译与 Windows API 调用Windows 程序经常需要嵌入图标、版本信息、清单文件这些通过 .rc 资源文件描述用 windres 编译。#include windows.h IDI_MAINICON ICON app.ico VS_VERSION_INFO VERSIONINFO FILEVERSION 1,0,0,1 PRODUCTVERSION 1,0,0,1 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE CompanyName, My Company VALUE FileDescription, MinGW-i686 Demo VALUE FileVersion, 1.0.0.1 VALUE ProductName, Demo App END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200 END END编译资源windres -i app.rc -o app_res.o --input-formatrc --output-formatcoff。然后把 app_res.o 加到链接命令里。注意--output-formatcoff是必须的因为 MinGW 链接器认的是 COFF 格式的目标文件。如果资源里引用了图标文件路径要相对于 .rc 文件所在目录或者用绝对路径。调用 Windows API 时MinGW 的头文件里默认用的是 ANSI 版本除非定义了 UNICODE 和 _UNICODE。如果你要写宽字符版本编译时加-DUNICODE -D_UNICODE然后调用GetSystemDirectoryW而不是GetSystemDirectoryA。混用 A 和 W 版本会导致链接错误或运行时乱码这是新手常踩的坑。4. MinGW-i686 避坑排查五个血泪经验4.1 编译报错 undefined reference to__imp_xxx现象链接阶段报一堆 undefined reference函数名带__imp_前缀。原因这些是 Windows API 的导入符号说明对应的系统库没链接。解决根据函数名判断所属库比如__imp_CreateFileA在 kernel32__imp_MessageBoxA在 user32__imp_RegOpenKeyExA在 advapi32。在链接命令里加上对应的-l参数。如果不知道函数在哪个库用nm -A /path/to/mingw/lib/*.a | grep FunctionName反查。4.2 生成的 exe 在别的机器上提示缺少 libgcc_s_dw2-1.dll现象本机运行正常拷到测试机报缺少 DLL。原因默认动态链接了 GCC 运行库而目标机器没装 MinGW。解决编译时加-static-libgcc -static-libstdc或者直接加-static全静态链接。验证方法用objdump -p app.exe | findstr DLL Name列出所有依赖的 DLL除了系统自带的 msvcrt、kernel32、user32 等不应该有其他非系统 DLL。4.3 windres 编译资源时报preprocessing failed现象windres 处理 .rc 文件时报预处理失败或者找不到 windows.h。原因windres 默认会调用预处理器但没带正确的 include 路径。解决加-I参数指定 MinGW 的 include 目录或者用--preprocessor-arg-I/path/to/include。更简单的做法是先用 gcc 预处理 .rc 文件gcc -E -xc -DRC_INVOKED app.rc -o app_pre.rc再用 windres 编译预处理后的文件。4.4 CMake 找到的是 MSVC 而不是 MinGW现象用 CMake 生成构建系统时编译器被识别成 cl.exe。原因CMake 默认优先找 MSVC或者 PATH 里 MSVC 在前面。解决在 toolchain 文件里显式设置 CMAKE_C_COMPILER 和 CMAKE_CXX_COMPILER 的完整路径并在命令行加-G MinGW Makefiles指定生成器。如果之前生成过缓存先删掉 CMakeCache.txt 和 CMakeFiles 目录再重新生成。4.5 32 位程序在 64 位系统上跑不起来现象编译出的 exe 在 64 位 Windows 上双击没反应或报错。原因可能误用了 64 位工具链或者链接了 64 位的库。解决用gcc -dumpmachine确认目标三元组是 i686 开头用objdump -f app.exe确认 architecture 是 i386。如果确实需要 64 位换 MinGW-w64 的 x86_64 版本不要试图用 i686 工具链生成 64 位代码。5. 进阶技巧用 MinGW-i686 交叉编译 Qt 与静态库封装5.1 为 Qt 项目配置 MinGW-i686 工具链Qt 在 Windows 上官方提供的预编译包通常只带 MinGW 64 位或 MSVC 版本如果你需要 32 位 Qt 程序要么自己从源码编译 Qt要么用 Qt 的 32 位 MinGW 构建。假设你已经有了 32 位的 Qt 库在 .pro 文件里需要指定编译器路径和库路径。# mingw32-qt.pro QT core gui widgets TARGET QtMinGW32App TEMPLATE app QMAKE_CC D:/tools/mingw32/bin/gcc.exe QMAKE_CXX D:/tools/mingw32/bin/g.exe QMAKE_LINK D:/tools/mingw32/bin/g.exe QMAKE_RC D:/tools/mingw32/bin/windres.exe QMAKE_CFLAGS -m32 QMAKE_CXXFLAGS -m32 QMAKE_LFLAGS -m32 -static-libgcc -static-libstdc INCLUDEPATH D:/Qt/5.15.2/mingw81_32/include LIBS -LD:/Qt/5.15.2/mingw81_32/lib -lQt5Core -lQt5Gui -lQt5Widgets配置完成后用qmake mingw32-qt.pro生成 Makefile再mingw32-make。注意 Qt 的版本要和 MinGW 的 ABI 兼容Qt 5.15 的 mingw81_32 是用 GCC 8.1 编译的你的 MinGW-i686 版本不能低于这个否则链接时可能报 ABI 不匹配。如果报undefined reference to std::__cxx11::basic_string之类的错误说明 GCC 版本差异导致 ABI 不兼容需要换用和 Qt 构建时相同版本的 MinGW。5.2 静态库的创建与封装把常用功能封装成静态库可以避免每次编译都重复处理相同的源码。创建静态库用 ar 命令gcc -O2 -m32 -c utils.c -o utils.o gcc -O2 -m32 -c net.c -o net.o ar rcs libmyutils.a utils.o net.oar rcs里 r 表示插入或替换c 表示创建s 表示生成索引。生成的 libmyutils.a 可以和其他目标文件一起链接gcc -m32 main.o -L. -lmyutils -o app.exe。注意库名要以 lib 开头链接时用 -l 加去掉 lib 前缀和 .a 后缀的名字。如果静态库依赖其他库链接顺序很重要。GNU 链接器从左到右处理库后面的库可以解析前面库的未定义符号反过来不行。所以依赖别人的库要放在被依赖库的右边。比如 libmyutils.a 用了 user32 的函数链接命令要写成-lmyutils -luser32不能反过来。如果循环依赖可以用-Wl,--start-group -lA -lB -Wl,--end-group让链接器反复扫描。5.3 用 gdb 调试 32 位程序MinGW-i686 自带的 gdb 可以调试生成的 exe。编译时加-g生成调试信息然后gdb app.exe启动。常用命令break main在 main 函数下断点run开始执行next单步跳过step单步进入print var打印变量bt看调用栈info registers看寄存器。如果程序崩溃gdb 会停在出错位置用bt可以看到完整的调用链。有个细节32 位程序的调用约定和 64 位不同参数通过栈传递而不是寄存器。在 gdb 里看汇编时esp指向栈顶ebp是帧指针。如果栈被破坏bt可能显示不全这时候用x/20x $esp直接看栈内存结合info symbol解析地址对应的函数名。调试 Release 版本时因为优化会打乱代码顺序断点可能不准建议调试时用-O0 -g编译。从那以后我每次拿到新的 MinGW 包第一件事就是跑gcc -dumpmachine和objdump -f确认目标架构再写一个最小工程验证编译、链接、资源、调试四条链路都通才敢往正式项目里接。希望帮到你。本文还有配套的精品资源点击获取 MinGW-i686 32位Windows编译链实战：配置、避坑与Qt交叉编译
简介MinGW-i686 是一套面向 Windows 平台的开源开发工具集专为 i686 架构传统 32 位 x86 处理器打造适合习惯 Linux 命令行开发环境、又需要在 Windows 上构建原生 32 位程序的开发者与学习者。包内集成 GCC 多语言编译器、GDB 调试器、Make 自动化构建工具、Binutils 二进制处理工具及 MSYS 类 Unix 环境覆盖编译、链接、调试与项目构建全流程。资源共约 2000 个文件以 h 头文件1207 个、hpp266 个、a 静态库219 个为主另有 exe 可执行程序、tcc、log 日志及 idl、dlg 等类型压缩包约 47.26MB目录结构完整便于按模块查阅与配置。目前已有 712 人学习下载。解压后可将 bin 目录加入系统 PATH 环境变量即可在命令提示符或 PowerShell 中直接调用工具链readme.txt 提供安装与使用说明mingw64 目录还附带 64 位工具链方便处理不同架构需求是 Windows 下开发 32 位应用的实用工具集。1. MinGW-i686 开发工具集32 位 Windows 原生编译链的最后一公里如果你还在维护一套十年前的 C/C 工程或者要给老旧的工业控制软件打补丁大概率会遇到一个绕不开的问题目标机器是 32 位 Windows而手头只有 64 位的 MSVC 工具链。这时候 MinGW-i686 就成了少数能救场的方案。它本质上是把 GCC 工具链移植到 Windows 平台的一套开发工具集i686 这个后缀明确指向 32 位 x86 架构生成的是不依赖第三方运行库的原生 PE 文件。和 MSVC 最大的区别在于MinGW 走的是 GNU 那套工具链习惯Makefile、CMake、Autotools 基本可以原样搬过来不需要为了迁就 cl.exe 去改构建脚本。这套资源适合三类人需要维护 32 位遗留项目的工程师、想用 GCC 但不想装完整 Cygwin 的开发者、以及教学场景里需要统一工具链的环境。下面从工具集的实际构成开始拆把安装、配置、踩坑和验证一条线走完。2. MinGW-i686 工具集拆解从 bin 目录到链接器参数2.1 工具集里到底装了些什么拿到 MinGW-i686 的包之后第一件事是搞清楚目录结构。典型的安装根目录下会有 bin、include、lib、libexec、share 这几个文件夹。bin 目录是核心里面放着 gcc.exe、g.exe、gfortran.exe、windres.exe、mingw32-make.exe、ar.exe、ld.exe、objdump.exe、gdb.exe 这些可执行文件。include 放的是 C 和 C 标准库以及 Windows API 的头文件lib 里是静态库和导入库libexec 里是 gcc 内部调用的子程序share 里是文档和本地化信息。这里有个容易混淆的点MinGW 和 MinGW-w64 不是一回事。MinGW 原版项目在 2013 年左右基本停更了对 C11 之后的标准支持有限而 MinGW-w64 是社区 fork 出来继续维护的版本同时支持 32 位和 64 位目标。你拿到的这个 i686 包如果是较新的构建底层很可能是 MinGW-w64 的 32 位目标版本只是沿用了 MinGW 的叫法。判断方法很简单在命令行里跑gcc -v看输出里的 Target 字段是不是i686-w64-mingw32如果是那就是 MinGW-w64 的 32 位构建。工具集里几个关键组件的职责需要分清楚。gcc 是编译器驱动负责调用预处理器、编译器、汇编器和链接器g 是 C 前端windres 用来编译 Windows 资源文件.rc生成 .o 或 .resmingw32-make 是 GNU Make 的 Windows 移植版和 Linux 下的 make 用法一致只是文件名不同以免和系统里其他 make 冲突gdb 是调试器配合 gcc 的 -g 选项使用。2.2 环境变量配置与多版本共存安装完成后把 MinGW-i686 的 bin 目录加到系统 PATH 里是最直接的做法。但如果你机器上同时有 MSVC、Cygwin、MinGW-w64 64 位版本直接改系统 PATH 会引发工具链冲突。更稳妥的方式是用一个批处理脚本临时设置环境只在当前会话生效。echo off REM 保存当前 PATH避免污染全局环境 set OLD_PATH%PATH% set MINGW32_HOMED:\tools\mingw32 set PATH%MINGW32_HOME%\bin;%PATH% REM 验证工具链指向正确 where gcc gcc -dumpmachine REM 在这里执行编译命令 REM mingw32-make -f Makefile.mingw REM 恢复 PATH set PATH%OLD_PATH%这段脚本的逻辑是先把原始 PATH 存到 OLD_PATH然后把 MinGW-i686 的 bin 目录插到最前面这样 where gcc 找到的就是 32 位版本。gcc -dumpmachine会输出目标三元组i686 开头的才是我们要的。编译完成后恢复 PATH不影响其他会话。参数方面MINGW32_HOME 换成你自己的安装路径注意路径里不要有空格和中文否则 windres 处理资源文件时可能报错。如果你用 CMake 构建项目还需要在 CMakeLists.txt 或命令行里指定编译器。常见做法是写一个 toolchain 文件# mingw32-toolchain.cmake set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86) set(CMAKE_C_COMPILER D:/tools/mingw32/bin/gcc.exe) set(CMAKE_CXX_COMPILER D:/tools/mingw32/bin/g.exe) set(CMAKE_RC_COMPILER D:/tools/mingw32/bin/windres.exe) set(CMAKE_FIND_ROOT_PATH D:/tools/mingw32) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)配置时用cmake -DCMAKE_TOOLCHAIN_FILEmingw32-toolchain.cmake ..来生成构建系统。CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 设为 NEVER 是为了让 CMake 在宿主机上找构建工具而库和头文件只在 MinGW 目录下找避免误用系统里的其他版本。2.3 编译链接参数与运行时依赖MinGW-i686 默认生成的是动态链接到 msvcrt.dll 的可执行文件。msvcrt.dll 是 Windows 系统自带的 C 运行库从 Windows 2000 开始就存在所以生成的 exe 在绝大多数 Windows 机器上可以直接跑不需要额外带 DLL。但如果你用了 C 标准库的某些特性可能需要静态链接 libstdc 和 libgcc。g -O2 -m32 main.cpp utils.cpp -o app.exe ^ -static-libgcc -static-libstdc ^ -Wl,-Bstatic -lstdc -Wl,-Bdynamic这里-m32明确指定生成 32 位代码虽然工具链本身已经是 i686 目标但加上这个参数可以防止误用 64 位选项。-static-libgcc和-static-libstdc把 GCC 的运行库静态链进去减少对 libgcc_s_dw2-1.dll 和 libstdc-6.dll 的依赖。-Wl,-Bstatic和-Wl,-Bdynamic是传给链接器的选项控制后续库的链接方式。注意顺序静态库要放在动态库前面。如果你需要生成不依赖 msvcrt.dll 的完全静态版本可以加-static选项但这会把整个运行库都链进去生成的 exe 体积会明显增大。常见做法是先用-static-libgcc -static-libstdc减小依赖再用 Dependency Walker 或objdump -p app.exe | findstr DLL Name检查还缺哪些 DLL。3. 从源码到 exeMinGW-i686 编译流程实操3.1 一个最小 C 工程的完整构建先从一个最简单的 C 程序开始把整个流程跑通。新建一个 hello.c#include stdio.h #include windows.h int main(void) { // 调用 Windows API 获取系统目录验证链接是否正常 char buf[MAX_PATH]; GetSystemDirectoryA(buf, MAX_PATH); printf(Hello from MinGW-i686\n); printf(System dir: %s\n, buf); return 0; }编译命令gcc -O2 -Wall -m32 hello.c -o hello.exe -luser32-O2开优化-Wall开常用警告-m32指定 32 位目标-luser32链接 user32 库因为用到了 GetSystemDirectoryA。编译完成后用objdump -f hello.exe查看文件格式输出里 architecture 应该是 i386format 是 pei-i386。再用file hello.exe确认如果显示 PE32 executable (console) Intel 80386说明生成正确。如果编译时报undefined reference to GetSystemDirectoryA说明没链接 user32。MinGW 的链接器不会自动链接所有系统库用到哪个 API 就要显式加对应的 -l 参数。常见的库映射关系kernel32、user32、gdi32、advapi32、shell32、ole32、comctl32。不确定某个函数在哪个库时可以用grep -r FunctionName /path/to/mingw/include先找头文件再根据头文件里的 pragma comment 或文档确定库名。3.2 Makefile 与 mingw32-make 的配合手工敲编译命令只适合验证实际项目还是要用 Makefile。MinGW 自带的 mingw32-make 和 GNU Make 语法完全兼容但有几个 Windows 特有的注意点。CC gcc CXX g CFLAGS -O2 -Wall -m32 -DWIN32 -D_WINDOWS CXXFLAGS $(CFLAGS) -stdc11 LDFLAGS -m32 -static-libgcc -static-libstdc LIBS -luser32 -lkernel32 -lgdi32 SRCS main.c utils.c OBJS $(SRCS:.c.o) TARGET app.exe all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ $(LIBS) %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: del /Q *.o *.exe 2nul .PHONY: all clean这个 Makefile 里del /Q是 Windows 命令2nul把错误输出重定向到空设备避免文件不存在时报错。-DWIN32 -D_WINDOWS是预定义宏很多跨平台代码靠这些宏判断当前平台。$(SRCS:.c.o)是 Make 的替换引用把 .c 后缀换成 .o。执行时用mingw32-make -j4并行编译-j4表示同时跑 4 个任务具体数字按 CPU 核心数调整。有个坑要注意Makefile 里的缩进必须用 Tab不能用空格。很多编辑器默认把 Tab 转成空格导致missing separator错误。在 VSCode 里可以设置editor.insertSpaces: false针对 Makefile 文件或者用.editorconfig统一管理。3.3 资源文件编译与 Windows API 调用Windows 程序经常需要嵌入图标、版本信息、清单文件这些通过 .rc 资源文件描述用 windres 编译。#include windows.h IDI_MAINICON ICON app.ico VS_VERSION_INFO VERSIONINFO FILEVERSION 1,0,0,1 PRODUCTVERSION 1,0,0,1 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK StringFileInfo BEGIN BLOCK 040904b0 BEGIN VALUE CompanyName, My Company VALUE FileDescription, MinGW-i686 Demo VALUE FileVersion, 1.0.0.1 VALUE ProductName, Demo App END END BLOCK VarFileInfo BEGIN VALUE Translation, 0x409, 1200 END END编译资源windres -i app.rc -o app_res.o --input-formatrc --output-formatcoff。然后把 app_res.o 加到链接命令里。注意--output-formatcoff是必须的因为 MinGW 链接器认的是 COFF 格式的目标文件。如果资源里引用了图标文件路径要相对于 .rc 文件所在目录或者用绝对路径。调用 Windows API 时MinGW 的头文件里默认用的是 ANSI 版本除非定义了 UNICODE 和 _UNICODE。如果你要写宽字符版本编译时加-DUNICODE -D_UNICODE然后调用GetSystemDirectoryW而不是GetSystemDirectoryA。混用 A 和 W 版本会导致链接错误或运行时乱码这是新手常踩的坑。4. MinGW-i686 避坑排查五个血泪经验4.1 编译报错 undefined reference to__imp_xxx现象链接阶段报一堆 undefined reference函数名带__imp_前缀。原因这些是 Windows API 的导入符号说明对应的系统库没链接。解决根据函数名判断所属库比如__imp_CreateFileA在 kernel32__imp_MessageBoxA在 user32__imp_RegOpenKeyExA在 advapi32。在链接命令里加上对应的-l参数。如果不知道函数在哪个库用nm -A /path/to/mingw/lib/*.a | grep FunctionName反查。4.2 生成的 exe 在别的机器上提示缺少 libgcc_s_dw2-1.dll现象本机运行正常拷到测试机报缺少 DLL。原因默认动态链接了 GCC 运行库而目标机器没装 MinGW。解决编译时加-static-libgcc -static-libstdc或者直接加-static全静态链接。验证方法用objdump -p app.exe | findstr DLL Name列出所有依赖的 DLL除了系统自带的 msvcrt、kernel32、user32 等不应该有其他非系统 DLL。4.3 windres 编译资源时报preprocessing failed现象windres 处理 .rc 文件时报预处理失败或者找不到 windows.h。原因windres 默认会调用预处理器但没带正确的 include 路径。解决加-I参数指定 MinGW 的 include 目录或者用--preprocessor-arg-I/path/to/include。更简单的做法是先用 gcc 预处理 .rc 文件gcc -E -xc -DRC_INVOKED app.rc -o app_pre.rc再用 windres 编译预处理后的文件。4.4 CMake 找到的是 MSVC 而不是 MinGW现象用 CMake 生成构建系统时编译器被识别成 cl.exe。原因CMake 默认优先找 MSVC或者 PATH 里 MSVC 在前面。解决在 toolchain 文件里显式设置 CMAKE_C_COMPILER 和 CMAKE_CXX_COMPILER 的完整路径并在命令行加-G MinGW Makefiles指定生成器。如果之前生成过缓存先删掉 CMakeCache.txt 和 CMakeFiles 目录再重新生成。4.5 32 位程序在 64 位系统上跑不起来现象编译出的 exe 在 64 位 Windows 上双击没反应或报错。原因可能误用了 64 位工具链或者链接了 64 位的库。解决用gcc -dumpmachine确认目标三元组是 i686 开头用objdump -f app.exe确认 architecture 是 i386。如果确实需要 64 位换 MinGW-w64 的 x86_64 版本不要试图用 i686 工具链生成 64 位代码。5. 进阶技巧用 MinGW-i686 交叉编译 Qt 与静态库封装5.1 为 Qt 项目配置 MinGW-i686 工具链Qt 在 Windows 上官方提供的预编译包通常只带 MinGW 64 位或 MSVC 版本如果你需要 32 位 Qt 程序要么自己从源码编译 Qt要么用 Qt 的 32 位 MinGW 构建。假设你已经有了 32 位的 Qt 库在 .pro 文件里需要指定编译器路径和库路径。# mingw32-qt.pro QT core gui widgets TARGET QtMinGW32App TEMPLATE app QMAKE_CC D:/tools/mingw32/bin/gcc.exe QMAKE_CXX D:/tools/mingw32/bin/g.exe QMAKE_LINK D:/tools/mingw32/bin/g.exe QMAKE_RC D:/tools/mingw32/bin/windres.exe QMAKE_CFLAGS -m32 QMAKE_CXXFLAGS -m32 QMAKE_LFLAGS -m32 -static-libgcc -static-libstdc INCLUDEPATH D:/Qt/5.15.2/mingw81_32/include LIBS -LD:/Qt/5.15.2/mingw81_32/lib -lQt5Core -lQt5Gui -lQt5Widgets配置完成后用qmake mingw32-qt.pro生成 Makefile再mingw32-make。注意 Qt 的版本要和 MinGW 的 ABI 兼容Qt 5.15 的 mingw81_32 是用 GCC 8.1 编译的你的 MinGW-i686 版本不能低于这个否则链接时可能报 ABI 不匹配。如果报undefined reference to std::__cxx11::basic_string之类的错误说明 GCC 版本差异导致 ABI 不兼容需要换用和 Qt 构建时相同版本的 MinGW。5.2 静态库的创建与封装把常用功能封装成静态库可以避免每次编译都重复处理相同的源码。创建静态库用 ar 命令gcc -O2 -m32 -c utils.c -o utils.o gcc -O2 -m32 -c net.c -o net.o ar rcs libmyutils.a utils.o net.oar rcs里 r 表示插入或替换c 表示创建s 表示生成索引。生成的 libmyutils.a 可以和其他目标文件一起链接gcc -m32 main.o -L. -lmyutils -o app.exe。注意库名要以 lib 开头链接时用 -l 加去掉 lib 前缀和 .a 后缀的名字。如果静态库依赖其他库链接顺序很重要。GNU 链接器从左到右处理库后面的库可以解析前面库的未定义符号反过来不行。所以依赖别人的库要放在被依赖库的右边。比如 libmyutils.a 用了 user32 的函数链接命令要写成-lmyutils -luser32不能反过来。如果循环依赖可以用-Wl,--start-group -lA -lB -Wl,--end-group让链接器反复扫描。5.3 用 gdb 调试 32 位程序MinGW-i686 自带的 gdb 可以调试生成的 exe。编译时加-g生成调试信息然后gdb app.exe启动。常用命令break main在 main 函数下断点run开始执行next单步跳过step单步进入print var打印变量bt看调用栈info registers看寄存器。如果程序崩溃gdb 会停在出错位置用bt可以看到完整的调用链。有个细节32 位程序的调用约定和 64 位不同参数通过栈传递而不是寄存器。在 gdb 里看汇编时esp指向栈顶ebp是帧指针。如果栈被破坏bt可能显示不全这时候用x/20x $esp直接看栈内存结合info symbol解析地址对应的函数名。调试 Release 版本时因为优化会打乱代码顺序断点可能不准建议调试时用-O0 -g编译。从那以后我每次拿到新的 MinGW 包第一件事就是跑gcc -dumpmachine和objdump -f确认目标架构再写一个最小工程验证编译、链接、资源、调试四条链路都通才敢往正式项目里接。希望帮到你。本文还有配套的精品资源点击获取