简介MinGW-i686 是一套面向 Windows 平台的开源开发工具集专为 i686 架构传统 32 位 x86 处理器打造适合习惯 Linux 开发环境、又需要在 Windows 上构建原生 32 位程序的开发者与学习者。包内集成 GCC 多语言编译器、GDB 调试器、Make 自动化构建工具、Binutils 二进制处理工具及 MSYS 类 Unix 命令行环境可完成从源码编译、链接到调试的完整流程。资源共约 2000 个文件以 h、hpp 头文件为主辅以 a 静态库、exe 可执行程序、tcc 配置脚本及 log 日志等压缩包约 47.26MB目录结构完整便于按组件检索。目前已有 713 人学习下载。通过它可快速搭建 32 位编译环境掌握 PATH 环境变量配置、readme 阅读与工具链调用等要点为 Windows 下的 C/C 项目开发与问题排查提供实用支撑。1. MinGW-i686 开发工具集32 位 Windows 原生编译链的最后一公里如果你在 Windows 上编译过 C/C 项目大概率绕不开 MinGW 这个名字。而 MinGW-i686 特指面向 32 位 x86 Windows 的那套工具集——gcc、g、gdb、mingw32-make、windres 一整套。它解决的核心问题是不依赖 MSVC 运行库直接产出能在 Win32 上跑的原生 exe 和 dll。适合谁维护老旧 32 位工控上位机的、给遗留系统打补丁的、用 Qt 做嵌入式 HMI 但目标板只认 x86 的以及被 msvc 和 mingw 区别绕晕后想找一条轻量路线的开发者。这篇不讲官网下载页怎么点只讲拿到 MinGW-i686 之后怎么把它变成能干活的生产力工具。2. MinGW-i686 与 MSVC 的选型分水岭什么时候必须用它2.1 运行库依赖与分发成本的硬账MSVC 编译出来的 exe 默认依赖 msvcr120.dll、vcruntime140.dll 这类微软运行库。目标机器没装对应版本的 Redistributable程序直接弹窗报错。MinGW-i686 走的是 msvcrt.dll 这条路——这个库从 Windows 2000 开始就是系统自带不需要额外分发。对于需要往几十台甚至上百台老工控机部署工具的场景这个差异直接决定你要不要写一个批处理去静默安装运行库。另一个常被忽略的点是 ABI 兼容性。MinGW-i686 使用 GCC 的 C ABI和 MSVC 的 ABI 不互通。这意味着你不能把 MSVC 编译的静态库直接链进 MinGW 的工程。常见做法是要么全部源码用 MinGW 重新编译要么通过 C 接口的 dll 做边界隔离。我一般会在项目初期就定死工具链避免后期混链时出现一堆 undefined reference。2.2 交叉编译与 CMake 工具链文件的配合MinGW-i686 本身是运行在 Windows 上的原生编译器不是交叉编译器。但它的 i686 前缀让很多人误以为它是从 Linux 交叉编译到 Windows。真正的交叉编译场景是在 Linux 上用 mingw-w64 的 i686-w64-mingw32-gcc 产出 Windows 32 位程序。如果你是在 Windows 上直接用 MinGW-i686那它就是本机编译器不需要额外配置 sysroot。用 CMake 管理工程时关键是指定编译器路径和调整搜索顺序。下面是一个最小可用的 CMake 工具链配置片段# toolchain-mingw-i686.cmake set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86) # 指定 MinGW-i686 的安装根目录按实际路径改 set(TOOLCHAIN_ROOT C:/mingw32) set(CMAKE_C_COMPILER ${TOOLCHAIN_ROOT}/bin/gcc.exe) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/g.exe) set(CMAKE_RC_COMPILER ${TOOLCHAIN_ROOT}/bin/windres.exe) # 让 find_package 优先在工具链目录下找库和头文件 set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN_ROOT}) 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_SYSTEM_NAME 设为 Windows 告诉 CMake 目标平台CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 设为 NEVER 是为了让 CMake 仍然能在宿主机 PATH 里找 make、ninja 这类构建工具而不是去 MinGW 目录里翻。参数怎么改TOOLCHAIN_ROOT 换成你解压 MinGW-i686 的实际路径注意用正斜杠或双反斜杠CMake 对反斜杠转义很敏感。配置完成后构建命令是cmake -B build -G MinGW Makefiles -DCMAKE_TOOLCHAIN_FILEtoolchain-mingw-i686.cmake cmake --build build -j8这里 -G MinGW Makefiles 指定生成器-j8 是并行编译核数按你机器调整。如果报错说找不到 mingw32-make检查 MinGW-i686 的 bin 目录是否在 PATH 里。2.3 静态链接与动态链接的取舍MinGW-i686 默认动态链接 libgcc 和 libstdc。这意味着你编译出的 exe 依赖 libgcc_s_dw2-1.dll 和 libstdc-6.dll。分发时要么带上这两个 dll要么加静态链接选项g main.cpp -o app.exe -static -static-libgcc -static-libstdc -lpthread-static 让所有库静态链接-static-libgcc 和 -static-libstdc 分别针对 GCC 运行库和 C 标准库。代价是 exe 体积膨胀一个 hello world 可能从 50KB 涨到 2MB。我一般会在发布版本用静态链接调试版本保持动态链接以加快编译速度。注意静态链接 pthread 时如果代码里用了 std::thread需要确保 -lpthread 放在编译命令末尾否则链接器可能报 undefined reference topthread_create。3. 从零搭建 MinGW-i686 可复现编译环境3.1 目录结构与 PATH 的干净配置拿到 MinGW-i686 压缩包后解压到一个不含空格和中文的路径比如 C:\mingw32。目录结构通常是C:\mingw32\ ├── bin\ # gcc.exe, g.exe, gdb.exe, mingw32-make.exe ├── include\ # 标准头文件和 win32api 头文件 ├── lib\ # 静态库和导入库 ├── libexec\ # gcc 内部程序 └── share\ # 文档和 licensePATH 里只需要加 C:\mingw32\bin。不要加 lib 或 include编译器自己知道去哪找。验证安装gcc --version g --version mingw32-make --version如果 gcc --version 输出的 target 是 i686-w64-mingw32 或 mingw32说明是 32 位版本。如果显示 x86_64-w64-mingw32那就是 64 位工具链编译出的 exe 在 32 位系统上跑不了。3.2 用 mingw32-make 跑通一个多文件工程假设有三个文件main.c、calc.c、calc.h。手写 Makefile 如下CC gcc CFLAGS -Wall -O2 -m32 LDFLAGS -m32 OBJS main.o calc.o TARGET app.exe all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: del /Q *.o $(TARGET)逻辑说明-m32 强制生成 32 位代码即使你的 MinGW 是 64 位版本也能产出 32 位目标文件前提是装了 multilib 支持。$ 是目标名$^ 是所有依赖$ 是第一个依赖。clean 用 del /Q 是 Windows 命令如果你在 git bash 里跑就改成 rm -f。执行构建mingw32-make如果报错 mingw32-make: *** No targets specified and no makefile found检查当前目录下文件名是 Makefile 还是 makefileWindows 不区分大小写但某些编辑器会存成 Makefile.txt。3.3 调试符号与 gdb 的配合MinGW-i686 自带 gdb。编译时加 -g 生成调试符号gcc -g -O0 -m32 -o app_debug.exe main.c calc.c gdb app_debug.exe进入 gdb 后常用命令break main 设断点run 启动next 单步跳过step 单步进入print 变量名 查看值bt 看调用栈。如果 gdb 启动时报 During startup program exited with code 0xc0000135说明缺 dll把 MinGW 的 bin 目录加到系统 PATH 或把 libgcc_s_dw2-1.dll 拷到 exe 同目录。提示-O2 和 -g 可以同时用但优化会打乱变量和行号的对应关系调试时建议用 -O0。4. MinGW-i686 避坑排查五个血泪翻车现场4.1 现象编译报错 undefined reference to__imp___iob_func原因这是 MSVC 和 MinGW 运行库差异的经典坑。某些第三方静态库是用 MSVC 编译的里面引用了 MSVC 特有的符号。MinGW 的 msvcrt.dll 不提供这个符号。解决找到该库的源码用 MinGW 重新编译。如果拿不到源码尝试在链接时加 -lmsvcrt 并定义 __USE_MINGW_ANSI_STDIO1但成功率不高。最稳妥的做法是换库或自己实现那部分功能。4.2 现象程序在 Win7 上跑正常在 Win10 上闪退原因MinGW-i686 默认可能链接了较新的 API或者用了不兼容的 manifest。Win10 对未声明 DPI 感知的程序有额外处理。解决编译时加 -mwindows 去掉控制台窗口如果是 GUI 程序并嵌入 manifestwindres app.rc -O coff -o app.res g main.cpp app.res -o app.exe -mwindowsapp.rc 内容1 24 app.manifestapp.manifest 里声明 supportedOS 和 dpiAware。4.3 现象中文路径下编译失败报 No such file or directory原因MinGW 的部分工具对 UTF-8 路径支持不完整尤其是老版本的 binutils。解决把工程放到纯英文路径下。如果必须用中文路径设置环境变量 LANGzh_CN.UTF-8 并确保源文件保存为 UTF-8 无 BOM 格式。我一般直接在 C:\work 下建工程省去这个玄学问题。4.4 现象链接时提示 cannot find -lstdc原因MinGW-i686 安装不完整或者 lib 目录下没有 libstdc.a。有些精简版工具集只包含 gcc 不包含 g。解决检查 C:\mingw32\lib 下是否有 libstdc.a 和 libstdc.dll.a。如果没有说明你下的是纯 C 编译器版本需要换完整版。另一个可能是 -L 路径写错了用 g -print-search-dirs 查看库搜索路径。4.5 现象用 CMake 生成 MinGW Makefiles 后make 报 CreateProcess: No such file or directory原因CMake 缓存了旧的编译器路径或者 PATH 里有多个 gcc 冲突。解决删掉 build 目录重新 cmake并在 CMakeCache.txt 里确认 CMAKE_C_COMPILER 指向的是 C:/mingw32/bin/gcc.exe 而不是其他路径。如果 PATH 里有多个 MinGW把不用的从 PATH 里移除。5. 让 MinGW-i686 融入现代工作流三个提效技巧5.1 用 ccache 加速重复编译MinGW-i686 本身不带 ccache但可以手动集成。下载 ccache 的 Windows 版本放到 PATH 里然后在 CMake 里设置find_program(CCACHE_PROGRAM ccache) if(CCACHE_PROGRAM) set(CMAKE_C_COMPILER_LAUNCHER ${CCACHE_PROGRAM}) set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE_PROGRAM}) endif()这样每次编译前 ccache 会检查缓存命中则直接返回目标文件。对于频繁改一个文件然后全量编译的工程速度提升非常明显。参数方面ccache -M 5G 设置缓存上限ccache -s 查看命中率。5.2 用 Qt 搭配 MinGW-i686 的版本对齐Qt 的 MinGW 版本对 ABI 很敏感。如果你用 Qt 5.15 的 MinGW 8.1 版本那你的 MinGW-i686 也必须是 8.1.0 的 i686 版本。版本不匹配会导致链接 Qt 库时报一堆 undefined reference。检查方法qmake -query QT_INSTALL_PREFIX gcc --version确保 Qt 安装目录下的 mkspecs 里 win32-g 的 QMAKE_COMPILER 版本和你的 gcc 一致。我一般直接从 Qt 安装器里勾选对应的 MinGW 组件不混用外部下载的版本。5.3 用 objdump 和 nm 排查符号问题当链接报 undefined reference 时用 nm 看目标文件里到底有没有这个符号nm -C main.o | grep 函数名 nm -C libfoo.a | grep 函数名-C 参数把 C 修饰名还原成可读形式。如果符号在 libfoo.a 里显示为 U未定义说明这个库本身还依赖别的库。如果显示为 T代码段或 W弱符号说明符号存在但可能被条件编译屏蔽了。objdump -p app.exe 可以查看 exe 依赖哪些 dll用来确认是否漏了运行库。提示MinGW-i686 的 nm 和 objdump 在 bin 目录下和 gcc 在一起。如果命令找不到检查 PATH。5.4 一个我踩过的坑-m32 和 -m64 混用有次接手一个项目Makefile 里 CFLAGS 写了 -m32但 LDFLAGS 忘了写。结果编译出的 .o 是 32 位链接时 gcc 默认按 64 位去链报 i386 architecture incompatible with i386:x86-64 output。解决就是确保 CFLAGS 和 LDFLAGS 都带 -m32。后来我养成了一个习惯在 Makefile 顶部定义 ARCH -m32然后 CFLAGS 和 LDFLAGS 都引用 $(ARCH)避免漏写。这个工具集不新甚至有点老派但在特定场景下它就是最省事的那把螺丝刀。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 12:10:42 · 阅读 1.2k MinGW-i686 实战指南：32 位 Windows 原生编译链配置与避坑
简介MinGW-i686 是一套面向 Windows 平台的开源开发工具集专为 i686 架构传统 32 位 x86 处理器打造适合习惯 Linux 开发环境、又需要在 Windows 上构建原生 32 位程序的开发者与学习者。包内集成 GCC 多语言编译器、GDB 调试器、Make 自动化构建工具、Binutils 二进制处理工具及 MSYS 类 Unix 命令行环境可完成从源码编译、链接到调试的完整流程。资源共约 2000 个文件以 h、hpp 头文件为主辅以 a 静态库、exe 可执行程序、tcc 配置脚本及 log 日志等压缩包约 47.26MB目录结构完整便于按组件检索。目前已有 713 人学习下载。通过它可快速搭建 32 位编译环境掌握 PATH 环境变量配置、readme 阅读与工具链调用等要点为 Windows 下的 C/C 项目开发与问题排查提供实用支撑。1. MinGW-i686 开发工具集32 位 Windows 原生编译链的最后一公里如果你在 Windows 上编译过 C/C 项目大概率绕不开 MinGW 这个名字。而 MinGW-i686 特指面向 32 位 x86 Windows 的那套工具集——gcc、g、gdb、mingw32-make、windres 一整套。它解决的核心问题是不依赖 MSVC 运行库直接产出能在 Win32 上跑的原生 exe 和 dll。适合谁维护老旧 32 位工控上位机的、给遗留系统打补丁的、用 Qt 做嵌入式 HMI 但目标板只认 x86 的以及被 msvc 和 mingw 区别绕晕后想找一条轻量路线的开发者。这篇不讲官网下载页怎么点只讲拿到 MinGW-i686 之后怎么把它变成能干活的生产力工具。2. MinGW-i686 与 MSVC 的选型分水岭什么时候必须用它2.1 运行库依赖与分发成本的硬账MSVC 编译出来的 exe 默认依赖 msvcr120.dll、vcruntime140.dll 这类微软运行库。目标机器没装对应版本的 Redistributable程序直接弹窗报错。MinGW-i686 走的是 msvcrt.dll 这条路——这个库从 Windows 2000 开始就是系统自带不需要额外分发。对于需要往几十台甚至上百台老工控机部署工具的场景这个差异直接决定你要不要写一个批处理去静默安装运行库。另一个常被忽略的点是 ABI 兼容性。MinGW-i686 使用 GCC 的 C ABI和 MSVC 的 ABI 不互通。这意味着你不能把 MSVC 编译的静态库直接链进 MinGW 的工程。常见做法是要么全部源码用 MinGW 重新编译要么通过 C 接口的 dll 做边界隔离。我一般会在项目初期就定死工具链避免后期混链时出现一堆 undefined reference。2.2 交叉编译与 CMake 工具链文件的配合MinGW-i686 本身是运行在 Windows 上的原生编译器不是交叉编译器。但它的 i686 前缀让很多人误以为它是从 Linux 交叉编译到 Windows。真正的交叉编译场景是在 Linux 上用 mingw-w64 的 i686-w64-mingw32-gcc 产出 Windows 32 位程序。如果你是在 Windows 上直接用 MinGW-i686那它就是本机编译器不需要额外配置 sysroot。用 CMake 管理工程时关键是指定编译器路径和调整搜索顺序。下面是一个最小可用的 CMake 工具链配置片段# toolchain-mingw-i686.cmake set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86) # 指定 MinGW-i686 的安装根目录按实际路径改 set(TOOLCHAIN_ROOT C:/mingw32) set(CMAKE_C_COMPILER ${TOOLCHAIN_ROOT}/bin/gcc.exe) set(CMAKE_CXX_COMPILER ${TOOLCHAIN_ROOT}/bin/g.exe) set(CMAKE_RC_COMPILER ${TOOLCHAIN_ROOT}/bin/windres.exe) # 让 find_package 优先在工具链目录下找库和头文件 set(CMAKE_FIND_ROOT_PATH ${TOOLCHAIN_ROOT}) 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_SYSTEM_NAME 设为 Windows 告诉 CMake 目标平台CMAKE_FIND_ROOT_PATH_MODE_PROGRAM 设为 NEVER 是为了让 CMake 仍然能在宿主机 PATH 里找 make、ninja 这类构建工具而不是去 MinGW 目录里翻。参数怎么改TOOLCHAIN_ROOT 换成你解压 MinGW-i686 的实际路径注意用正斜杠或双反斜杠CMake 对反斜杠转义很敏感。配置完成后构建命令是cmake -B build -G MinGW Makefiles -DCMAKE_TOOLCHAIN_FILEtoolchain-mingw-i686.cmake cmake --build build -j8这里 -G MinGW Makefiles 指定生成器-j8 是并行编译核数按你机器调整。如果报错说找不到 mingw32-make检查 MinGW-i686 的 bin 目录是否在 PATH 里。2.3 静态链接与动态链接的取舍MinGW-i686 默认动态链接 libgcc 和 libstdc。这意味着你编译出的 exe 依赖 libgcc_s_dw2-1.dll 和 libstdc-6.dll。分发时要么带上这两个 dll要么加静态链接选项g main.cpp -o app.exe -static -static-libgcc -static-libstdc -lpthread-static 让所有库静态链接-static-libgcc 和 -static-libstdc 分别针对 GCC 运行库和 C 标准库。代价是 exe 体积膨胀一个 hello world 可能从 50KB 涨到 2MB。我一般会在发布版本用静态链接调试版本保持动态链接以加快编译速度。注意静态链接 pthread 时如果代码里用了 std::thread需要确保 -lpthread 放在编译命令末尾否则链接器可能报 undefined reference topthread_create。3. 从零搭建 MinGW-i686 可复现编译环境3.1 目录结构与 PATH 的干净配置拿到 MinGW-i686 压缩包后解压到一个不含空格和中文的路径比如 C:\mingw32。目录结构通常是C:\mingw32\ ├── bin\ # gcc.exe, g.exe, gdb.exe, mingw32-make.exe ├── include\ # 标准头文件和 win32api 头文件 ├── lib\ # 静态库和导入库 ├── libexec\ # gcc 内部程序 └── share\ # 文档和 licensePATH 里只需要加 C:\mingw32\bin。不要加 lib 或 include编译器自己知道去哪找。验证安装gcc --version g --version mingw32-make --version如果 gcc --version 输出的 target 是 i686-w64-mingw32 或 mingw32说明是 32 位版本。如果显示 x86_64-w64-mingw32那就是 64 位工具链编译出的 exe 在 32 位系统上跑不了。3.2 用 mingw32-make 跑通一个多文件工程假设有三个文件main.c、calc.c、calc.h。手写 Makefile 如下CC gcc CFLAGS -Wall -O2 -m32 LDFLAGS -m32 OBJS main.o calc.o TARGET app.exe all: $(TARGET) $(TARGET): $(OBJS) $(CC) $(LDFLAGS) -o $ $^ %.o: %.c $(CC) $(CFLAGS) -c $ -o $ clean: del /Q *.o $(TARGET)逻辑说明-m32 强制生成 32 位代码即使你的 MinGW 是 64 位版本也能产出 32 位目标文件前提是装了 multilib 支持。$ 是目标名$^ 是所有依赖$ 是第一个依赖。clean 用 del /Q 是 Windows 命令如果你在 git bash 里跑就改成 rm -f。执行构建mingw32-make如果报错 mingw32-make: *** No targets specified and no makefile found检查当前目录下文件名是 Makefile 还是 makefileWindows 不区分大小写但某些编辑器会存成 Makefile.txt。3.3 调试符号与 gdb 的配合MinGW-i686 自带 gdb。编译时加 -g 生成调试符号gcc -g -O0 -m32 -o app_debug.exe main.c calc.c gdb app_debug.exe进入 gdb 后常用命令break main 设断点run 启动next 单步跳过step 单步进入print 变量名 查看值bt 看调用栈。如果 gdb 启动时报 During startup program exited with code 0xc0000135说明缺 dll把 MinGW 的 bin 目录加到系统 PATH 或把 libgcc_s_dw2-1.dll 拷到 exe 同目录。提示-O2 和 -g 可以同时用但优化会打乱变量和行号的对应关系调试时建议用 -O0。4. MinGW-i686 避坑排查五个血泪翻车现场4.1 现象编译报错 undefined reference to__imp___iob_func原因这是 MSVC 和 MinGW 运行库差异的经典坑。某些第三方静态库是用 MSVC 编译的里面引用了 MSVC 特有的符号。MinGW 的 msvcrt.dll 不提供这个符号。解决找到该库的源码用 MinGW 重新编译。如果拿不到源码尝试在链接时加 -lmsvcrt 并定义 __USE_MINGW_ANSI_STDIO1但成功率不高。最稳妥的做法是换库或自己实现那部分功能。4.2 现象程序在 Win7 上跑正常在 Win10 上闪退原因MinGW-i686 默认可能链接了较新的 API或者用了不兼容的 manifest。Win10 对未声明 DPI 感知的程序有额外处理。解决编译时加 -mwindows 去掉控制台窗口如果是 GUI 程序并嵌入 manifestwindres app.rc -O coff -o app.res g main.cpp app.res -o app.exe -mwindowsapp.rc 内容1 24 app.manifestapp.manifest 里声明 supportedOS 和 dpiAware。4.3 现象中文路径下编译失败报 No such file or directory原因MinGW 的部分工具对 UTF-8 路径支持不完整尤其是老版本的 binutils。解决把工程放到纯英文路径下。如果必须用中文路径设置环境变量 LANGzh_CN.UTF-8 并确保源文件保存为 UTF-8 无 BOM 格式。我一般直接在 C:\work 下建工程省去这个玄学问题。4.4 现象链接时提示 cannot find -lstdc原因MinGW-i686 安装不完整或者 lib 目录下没有 libstdc.a。有些精简版工具集只包含 gcc 不包含 g。解决检查 C:\mingw32\lib 下是否有 libstdc.a 和 libstdc.dll.a。如果没有说明你下的是纯 C 编译器版本需要换完整版。另一个可能是 -L 路径写错了用 g -print-search-dirs 查看库搜索路径。4.5 现象用 CMake 生成 MinGW Makefiles 后make 报 CreateProcess: No such file or directory原因CMake 缓存了旧的编译器路径或者 PATH 里有多个 gcc 冲突。解决删掉 build 目录重新 cmake并在 CMakeCache.txt 里确认 CMAKE_C_COMPILER 指向的是 C:/mingw32/bin/gcc.exe 而不是其他路径。如果 PATH 里有多个 MinGW把不用的从 PATH 里移除。5. 让 MinGW-i686 融入现代工作流三个提效技巧5.1 用 ccache 加速重复编译MinGW-i686 本身不带 ccache但可以手动集成。下载 ccache 的 Windows 版本放到 PATH 里然后在 CMake 里设置find_program(CCACHE_PROGRAM ccache) if(CCACHE_PROGRAM) set(CMAKE_C_COMPILER_LAUNCHER ${CCACHE_PROGRAM}) set(CMAKE_CXX_COMPILER_LAUNCHER ${CCACHE_PROGRAM}) endif()这样每次编译前 ccache 会检查缓存命中则直接返回目标文件。对于频繁改一个文件然后全量编译的工程速度提升非常明显。参数方面ccache -M 5G 设置缓存上限ccache -s 查看命中率。5.2 用 Qt 搭配 MinGW-i686 的版本对齐Qt 的 MinGW 版本对 ABI 很敏感。如果你用 Qt 5.15 的 MinGW 8.1 版本那你的 MinGW-i686 也必须是 8.1.0 的 i686 版本。版本不匹配会导致链接 Qt 库时报一堆 undefined reference。检查方法qmake -query QT_INSTALL_PREFIX gcc --version确保 Qt 安装目录下的 mkspecs 里 win32-g 的 QMAKE_COMPILER 版本和你的 gcc 一致。我一般直接从 Qt 安装器里勾选对应的 MinGW 组件不混用外部下载的版本。5.3 用 objdump 和 nm 排查符号问题当链接报 undefined reference 时用 nm 看目标文件里到底有没有这个符号nm -C main.o | grep 函数名 nm -C libfoo.a | grep 函数名-C 参数把 C 修饰名还原成可读形式。如果符号在 libfoo.a 里显示为 U未定义说明这个库本身还依赖别的库。如果显示为 T代码段或 W弱符号说明符号存在但可能被条件编译屏蔽了。objdump -p app.exe 可以查看 exe 依赖哪些 dll用来确认是否漏了运行库。提示MinGW-i686 的 nm 和 objdump 在 bin 目录下和 gcc 在一起。如果命令找不到检查 PATH。5.4 一个我踩过的坑-m32 和 -m64 混用有次接手一个项目Makefile 里 CFLAGS 写了 -m32但 LDFLAGS 忘了写。结果编译出的 .o 是 32 位链接时 gcc 默认按 64 位去链报 i386 architecture incompatible with i386:x86-64 output。解决就是确保 CFLAGS 和 LDFLAGS 都带 -m32。后来我养成了一个习惯在 Makefile 顶部定义 ARCH -m32然后 CFLAGS 和 LDFLAGS 都引用 $(ARCH)避免漏写。这个工具集不新甚至有点老派但在特定场景下它就是最省事的那把螺丝刀。希望帮到你。本文还有配套的精品资源点击获取