简介MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源适合在本地学习 C、希望摆脱大型 IDE 依赖的开发者与编程初学者。它提供 GCC、libstdc、Binutils、Make 及配套头文件与库支持 C11/14/17 标准及部分 C20 特性可命令行快速编译调试资源占用小、启动快编译产物跨平台兼容性较好。压缩包为 zip 格式整体约 156.05MB文件总数与类型明细上游暂未提供从描述可知核心为 TDM-GCC-64 分支的 64 位工具链包含编译器可执行文件、标准库与开发头文件等。目前已有 115 人浏览学习。借助该工具链读者可搭建轻量级 C 开发环境理解从源码到可执行文件的完整编译流程并利用 GCC 的稳定性与标准支持完成日常练习与小型项目构建。1. MinGW for Win64为什么你编译出的 exe 总在别人电脑上跑不起来你在自己机器上用 MinGW for Win64 编了个 exe双击能跑发给同事就报「缺少 libgcc_s_seh-1.dll」或者你装了 Qt选 MinGW 编译器构建一切正常一换 MSVC 就一堆链接错误。这类问题的根子几乎都不在代码而在「你到底装的是哪一套 MinGW、它默认链的是哪套运行时、产物依赖了哪些 DLL」这三件事上。MinGW for Win64 说的就是 Windows 64 位平台上的 Minimalist GNU for Windows 工具链用 GCC 系编译器产出原生 Windows 可执行文件不依赖额外的 POSIX 模拟层。它适合三类人想用 GCC/CMake 在 Windows 上做 C/C 开发的人、用 Qt 但不想被 MSVC 绑死的人、以及需要交叉编译或复现 Linux 构建脚本的人。这篇不聊虚的从选型、安装、CMake 配置一路讲到 DLL 依赖和踩坑排查让你把「能编」变成「编出来到处能跑」。2. MinGW for Win64 的发行版选型别在第一步就埋雷MinGW 本身是一套头文件和导入库的规范真正让你下载安装的是它的发行版。这一步选错后面 CMake、Qt、调试全是连锁反应。很多人搜「mingw官网下载」结果下到十几年前停更的 MinGW.org 版本或者随手装了个 32 位的这就是血泪经验的起点。2.1 MinGW.org、MinGW-w64、MSYS2 到底什么关系先把三个名字理清这是选型的地基MinGW.org最早的 MinGW 项目只做到 32 位更新基本停滞。现在还在用它的人多半是照着老教程走的不建议新项目采用。MinGW-w64为解决 64 位和更多 Windows API 支持而分出来的项目是当前 Win64 开发的事实标准。它提供两套线程模型win32 / posix和两套异常模型seh / sjlj这些参数直接决定你的程序行为和依赖。MSYS2一个在 Windows 上提供类 Unix shell 和包管理器pacman的环境它内部用的编译器就是 MinGW-w64。你可以把它理解成「MinGW-w64 的现代化分发 包管理」。所以当有人说「我装了 MinGW」他大概率装的是 MinGW-w64或者通过 MSYS2 装的 MinGW-w64。选型结论很直接新项目一律用 MinGW-w64推荐通过 MSYS2 安装因为包管理能帮你解决依赖、升级和版本对齐而不是手动解压一堆压缩包。2.2 线程模型和异常模型两个必须现在就定的参数这两个参数是 MinGW-w64 特有的选错了后期很难改参数可选值影响建议线程模型win32 / posixposix 支持 std::thread、std::mutex 等 C11 线程设施win32 不支持用 C 多线程就选 posix异常模型seh / sjljseh 是 64 位原生异常性能好sjlj 靠 setjmp/longjmp慢且 64 位下不推荐Win64 一律选 sehMSYS2 里对应的包名就能看出组合比如mingw-w64-x86_64-gcc默认就是 posix 线程 seh 异常。如果你手动下载压缩包文件名里通常带posix-seh或win32-sjlj字样认准x86_64posixseh这套组合基本不会错。注意线程模型选 win32 后代码里用std::thread会直接编译失败或链接报错这不是你代码的问题是工具链不支持。换工具链比改代码省事。2.3 用 MSYS2 装一套干净的 MinGW-w64下面是我一般会走的安装流程全程命令行可复现# 1. 安装 MSYS2 后打开 MSYS2 UCRT64 或 MINGW64 终端 # 更新包数据库和基础包 pacman -Syu # 2. 如果上一步提示关闭终端重开就重开后再执行一次 pacman -Su # 3. 安装 64 位 MinGW-w64 工具链UCRT64 环境 pacman -S mingw-w64-ucrt-x86_64-gcc \ mingw-w64-ucrt-x86_64-gdb \ mingw-w64-ucrt-x86_64-cmake \ mingw-w64-ucrt-x86_64-ninja # 4. 验证 gcc --version g --version cmake --version逻辑说明pacman -Syu先同步数据库再升级已装包第一次跑完常要求重启终端这是 MSYS2 的固定套路不是出错。第 3 步一次把编译器、调试器、构建系统装齐避免后面缺 gdb 或 cmake 再回来补。ucrt指的是使用 Universal C Runtime是较新的运行时方案比老的 msvcrt 更贴近现代 Windows。参数说明包名前缀mingw-w64-ucrt-x86_64-表示「64 位 UCRT 运行时」的工具链。如果你在 MINGW64 环境里前缀是mingw-w64-x86_64-用的是 msvcrt 运行时。两者不要混装混用否则链接阶段会出现运行时符号冲突。装完后把C:\msys64\ucrt64\bin或对应环境的 bin 目录加进系统 PATH这样在普通 CMD 或 PowerShell 里也能直接调gcc、cmake。这一步不做后面在 IDE 里配编译器路径会反复找不到。3. 用 CMake 驱动 MinGW for Win64从 hello 到可分发产物装好工具链只是开始真正决定你能不能顺利构建的是构建系统怎么调它。CMake 与 MinGW 的组合是 Windows 上 GCC 开发最常见的搭配但「指定编译器」和「指定生成器」这两件事经常被搞混导致 CMake 偷偷用了别的编译器。3.1 最小可复现工程CMakeLists 与构建命令先建一个最小工程把链路跑通再谈复杂项目。# CMakeLists.txt cmake_minimum_required(VERSION 3.20) project(hello_mingw CXX) # 强制使用 C17MinGW-w64 的 GCC 版本一般都能满足 set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(hello main.cpp) # 关键把 GCC 运行时静态链接进 exe减少 DLL 依赖 if(MINGW) target_link_options(hello PRIVATE -static-libgcc -static-libstdc -static) endif()// main.cpp #include iostream #include thread int main() { std::cout MinGW for Win64 build ok\n; // 验证 posix 线程模型是否生效 std::thread t([] { std::cout thread running\n; }); t.join(); return 0; }构建命令关键是显式指定生成器和编译器# 在工程目录下用 Ninja 生成器 明确指定 gcc/g cmake -S . -B build -G Ninja \ -DCMAKE_C_COMPILERgcc \ -DCMAKE_CXX_COMPILERg \ -DCMAKE_BUILD_TYPERelease cmake --build build逻辑说明-G Ninja指定生成器Ninja 比默认的 MinGW Makefiles 更快也更少路径坑。-DCMAKE_CXX_COMPILERg是硬性指定编译器防止 CMake 在 PATH 里抓到 MSVC 的cl.exe或别的 gcc。-DCMAKE_BUILD_TYPERelease决定优化级别MinGW 单配置生成器必须显式给否则默认无优化。参数说明-static-libgcc -static-libstdc让 GCC 和 C 标准库静态进 exe-static进一步把其他依赖也静态化。代价是 exe 变大收益是换台机器不用带一堆 DLL。要不要全静态取决于你的分发场景见下一节。3.2 动态链接还是静态链接DLL 依赖的取舍MinGW 默认是动态链接运行时的所以你的 exe 会依赖libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll这几个。这就是开头那个「同事电脑跑不起来」的直接原因。两种策略全静态加-static产物自包含分发最省心。缺点是体积大且如果多个模块各自静态链接了运行时跨模块传 C 对象比如异常、string可能出问题。动态 随包 DLL保持默认把依赖的 DLL 和 exe 放一起。适合插件式架构或需要共享运行时的场景。用objdump或ntldd查依赖这是排查「缺 DLL」的后悔药# 查看 exe 依赖了哪些 DLL objdump -p build/hello.exe | grep DLL Name # 或者用 MSYS2 里的 ntldd ntldd -R build/hello.exe逻辑说明objdump -p打印 PE 文件的所有头信息grep DLL Name过滤出导入表里的 DLL 列表。ntldd -R递归解析依赖树能看出间接依赖。发布前跑一遍把非系统 DLL 全部随包带上就不会再出现「我这儿能跑」的玄学。3.3 在 Qt 里挂 MinGW 编译器路径和 kit 怎么配Qt 用户搜「qt 按照完 mingw 编译器后」多半卡在 kit 配置。要点是Qt 的 MinGW 版本必须和你的 Qt 库版本匹配位数一致都是 64 位线程/异常模型一致。配置步骤打开 Qt Creator进入「工具 → 选项 → Kits → 编译器」添加一个 Manual C 编译器路径指向C:\msys64\ucrt64\bin\g.exe。在「构建套件Kit」里新建一个 Kit编译器选刚加的 g调试器指向gdb.exeQt 版本选你安装的 MinGW 版 Qt。确认 Kit 没有黄色感叹号否则说明某个组件路径不对。注意不要拿 MSVC 编译的 Qt 库去配 MinGW 编译器ABI 不兼容链接阶段会报一堆找不到符号。Qt 官方安装器里 MinGW 版和 MSVC 版是分开的装哪个就用哪个编译器。4. MinGW 与 MSVC 的差异什么时候该换、什么时候别硬扛搜「msvc 和 mingw 区别」的人通常是在某个环节撞墙了。两者不是谁替代谁而是两套 ABI 和生态。理解差异才能判断当前项目该不该换工具链。4.1 ABI、运行时与调试体验的实质区别维度MinGW-w64 (GCC)MSVCC ABI自有 ABI与 MSVC 不兼容微软 ABI标准库libstdcMSVC STL运行时UCRT / msvcrtUCRT / VCRuntime调试器gdbVisual Studio Debugger与 Windows SDK兼容但部分新 API 支持滞后原生最佳跨平台构建脚本与 Linux GCC 高度一致需额外适配核心结论两者编译出的 C 目标文件不能互相链接。你不能用 MinGW 编一个静态库再拿 MSVC 的主程序去链。混用只在纯 C 接口extern C层面才安全。4.2 该用 MinGW 还是 MSVC 的判断清单项目已有 Linux 构建脚本、大量 GCC 特有扩展用 MinGW迁移成本最低。依赖 Windows 专有库、COM、ATL、或需要和 MSVC 编译的第三方库对接用 MSVC。用 Qt 且不想装几个 G 的 Visual Studio用 MinGW 版 Qt轻量。需要和 Windows 驱动、系统级 API 深度交互用 MSVCSDK 支持更完整。团队统一用 VS 生态、CI 跑在 Windows Agent 上用 MSVC省心。我一般的习惯是跨平台命令行工具、开源库复现、Qt 小工具用 MinGW一旦涉及 Windows 平台深度集成或要链接商业 SDK果断切 MSVC别硬扛。4.3 从 MinGW 切到 MSVC 时最容易翻车的三处编译选项不通用-static-libgcc、-Wall这类 GCC 选项在 MSVC 下无效要换成/MT、/W4。CMake 里用if(MINGW)/if(MSVC)分支处理。源码里的 GCC 扩展__attribute__、变长数组、typeof等 MSVC 不支持需要条件编译或改写。第三方库 ABI你依赖的库如果是 MinGW 编的切 MSVC 后必须换成 MSVC 版否则链接必挂。CMake 里做编译器分支的常见写法if(MSVC) target_compile_options(app PRIVATE /W4 /MT) elseif(MINGW) target_compile_options(app PRIVATE -Wall -Wextra) target_link_options(app PRIVATE -static) endif()逻辑说明用生成器表达式或条件分支把编译器相关选项隔离同一份 CMakeLists 就能同时支持两套工具链。这样切换时只改-DCMAKE_CXX_COMPILER不用动工程文件。5. MinGW for Win64 避坑排查五个我真实踩过的坑这一章全是现象、原因、解决三件套都是能直接对号入座的。5.1 编译通过但运行报缺少 libgcc_s_seh-1.dll现象本机双击 exe 正常拷到别的机器报缺少libgcc_s_seh-1.dll或libstdc-6.dll。原因默认动态链接 GCC 运行时目标机器没装 MinGW自然找不到这些 DLL。解决要么加-static-libgcc -static-libstdc -static全静态要么用ntldd -R列出所有非系统 DLL随 exe 一起打包。发布前一定在干净机器或虚拟机验证一次。5.2 CMake 报找不到编译器或用了错误的编译器现象cmake -G MinGW Makefiles报CMAKE_C_COMPILER not found或者构建时调用了 MSVC。原因PATH 里同时有多个编译器CMake 缓存了上一次的配置。解决删掉build目录和CMakeCache.txt重新配置并显式传-DCMAKE_C_COMPILERgcc -DCMAKE_CXX_COMPILERg。切换工具链时永远清缓存这是铁律。5.3 std::thread 编译报错或链接失败现象代码里用std::thread编译报thread is not a member of std或链接报undefined reference to pthread_create。原因装的是 win32 线程模型的 MinGW-w64不支持 C11 线程或者没链接 pthread。解决换 posix 线程模型的工具链MSYS2 默认就是。若确实要用 win32 模型得改用 Windows 原生线程 API。链接层面加-lpthread有时能救但根治还是换工具链。5.4 中文路径或空格路径导致构建失败现象工程放在含中文或空格的目录下make 或 gcc 报奇怪的路径错误。原因部分构建工具和脚本对非 ASCII 路径、空格处理不完善。解决工程路径全用英文、无空格比如D:\work\proj。这是最省事的规避方式别跟工具链较劲。5.5 静态链接后异常跨模块传播崩溃现象主程序和 DLL 各自静态链接了 libstdcDLL 抛异常主程序 catch 不到或直接崩溃。原因两套独立的 C 运行时异常对象和类型信息不共享。解决跨模块边界要么统一动态链接同一份运行时要么在边界处把异常转成错误码。纯 C 接口是最稳的边界设计。6. 让 MinGW for Win64 产物真正可分发一个发布前自检脚本前面讲的都是「怎么编出来」最后一章落到「怎么保证编出来的东西别人能用」。我自己的习惯是写一个发布前自检脚本把依赖检查、静态性验证、版本信息一次性跑完避免每次手动objdump漏看。#!/usr/bin/env bash # release_check.sh - MinGW for Win64 产物发布前自检 set -euo pipefail EXE${1:?用法: ./release_check.sh path/to/app.exe} echo 1. 检查文件类型和架构 file $EXE echo 2. 列出所有非系统 DLL 依赖 # 系统 DLL 一般位于 C:\Windows\System32这里只提示需要随包的 objdump -p $EXE | grep DLL Name | awk {print $3} | sort -u echo 3. 检查是否静态链接了 GCC 运行时 if objdump -p $EXE | grep -qi libgcc_s; then echo [警告] 仍动态依赖 libgcc_s分发需带 DLL 或改 -static else echo [OK] 未发现 libgcc_s 动态依赖 fi echo 4. 打印编译器版本便于归档 g --version | head -n 1 echo 5. 在干净环境验证手动步骤 echo 请把 exe 拷到未装 MinGW 的机器或全新虚拟机双击运行确认逻辑说明脚本分五步先确认产物架构对不对别把 32 位当 64 位发再列依赖然后专门检查libgcc_s是否还在动态依赖里接着记录编译器版本方便复现最后提醒做干净环境验证。set -euo pipefail保证任何一步失败就停不会带着错误继续。参数说明$1是 exe 路径必填。objdump -p输出里DLL Name后面就是依赖名awk {print $3}取第三列。判断静态性用grep -qi-q静默、-i忽略大小写。这套脚本可以直接进 CI作为发布流水线的一道卡口。再补一个进阶技巧如果你要同时出静态版和动态版用 CMake 的BUILD_SHARED_LIBS加自定义 option 控制而不是维护两份工程。构建目录分开build-static/build-shared配置时传不同参数产物互不污染。我自己这些年最大的教训就是MinGW 的问题九成不在编译而在「你以为它静态了其实没有」「你以为 PATH 里是这套 gcc 其实是那套」。每次发布前老老实实跑一遍依赖检查比事后被用户追着问「为什么打不开」省太多事。希望帮到你。本文还有配套的精品资源点击获取