简介MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源适合希望在本地编写、编译 C 程序的开发者与编程学习者尤其适合不依赖大型 IDE、偏好命令行操作的人群。压缩包为 zip 格式整体约 156.05MB内含 TDM-GCC-64 分支集成 64 位 GCC 工具链支持 C11、C14、C17 标准及部分 C20 特性。资源涵盖 GCC 编译器、libstdc 标准库、Binutils 链接与汇编工具、Make 自动化构建工具以及开发所需的头文件和静态、动态库可满足从源码编译到可执行程序生成的完整流程。借助它读者能快速搭建轻量级本地 C 开发环境通过命令行理解编译与调试过程并利用 64 位编译优势提升程序运行效率。目前已有 115 人学习下载适合需要稳定 GCC 支持、追求轻量高效开发体验的 C 学习者与开发者参考使用。1. MinGW for Win64为什么你编译的 exe 在别人机器上跑不起来你在自己电脑上用 MinGW for Win64 编译出一个 exe双击运行一切正常发给同事却弹窗报错「缺少 libgcc_s_seh-1.dll」或者「找不到 libstdc-6.dll」。这不是代码写错了而是 MinGW 在 Win64 下的动态链接模型和运行库分发方式没搞对。MinGW for Win64 指的是在 64 位 Windows 上使用 GCC 工具链进行原生编译的整套方案核心产物是 PE32 格式的 exe 和 dll不依赖任何中间虚拟机。它解决的是「不想装 Visual Studio、又想用 GCC 生态写 Windows 原生程序」这个需求适合做命令行工具、嵌入式上位机、Qt 桌面应用以及需要跨平台编译的 C/C 项目。很多人第一次接触 MinGW 是从 mingw 官网下载开始的但下载哪个包、选什么线程模型、怎么配 CMake每一步都有分叉。2. MinGW-w64 工具链选型从 mingw 官网下载到第一次编译通过2.1 为什么是 MinGW-w64 而不是老 MinGW老 MinGW 项目在 64 位支持上长期停滞MinGW-w64 是社区分叉出来专门解决 Win64 目标的工具链。它同时支持 32 位和 64 位目标头文件覆盖更完整的 Windows API对 SEH结构化异常处理和 DWARF 调试信息的支持也更靠谱。你在网上搜 mingw 下载排在前面的基本都是 MinGW-w64 的衍生发行版而不是原始 MinGW。选型时第一个要确认的就是目标架构x86_64 对应 64 位 Windowsi686 对应 32 位。如果你只做 Win64直接锁定 x86_64 即可不要装 i686 版本否则后面链接系统库时会遇到架构不匹配的报错。第二个要确认的是线程模型。MinGW-w64 提供 win32 和 posix 两种线程实现。win32 线程模型直接用 Windows 原生线程 API不依赖额外运行库编译出的程序体积小、启动快posix 线程模型通过一层封装提供 pthread 接口如果你用的第三方库依赖 pthread就必须选 posix。常见做法是纯 Windows 原生开发选 win32需要跨平台移植或依赖 pthread 的选 posix。这个选择在安装后不能轻易切换装错了只能重装。第三个是异常处理模型。64 位下只有 SEH 可用32 位下才有 SJLJ 和 DWARF 之分。所以只要你做 Win64异常模型基本没有选择余地SEH 是唯一正确选项。如果你看到某个发行版在 64 位下还提供 SJLJ那说明它的打包方式比较老不建议用。2.2 安装方式安装器、压缩包与包管理器MinGW-w64 本身不提供官方安装器你下载到的都是第三方打包。常见的有 MSYS2 的 pacman 包管理、w64devkit 的单文件压缩包、以及 SourceForge 上的独立构建。我一般推荐两条路一是用 MSYS2二是用 w64devkit。MSYS2 的好处是包管理方便后续装 CMake、Ninja、pkg-config 都是一条命令w64devkit 的好处是解压即用不污染系统环境适合放在 U 盘里随身带。用 MSYS2 安装 MinGW-w64 的命令如下# 更新 MSYS2 基础包 pacman -Syu # 安装 64 位 MinGW-w64 工具链 pacman -S mingw-w64-x86_64-gcc # 安装配套构建工具 pacman -S mingw-w64-x86_64-cmake mingw-w64-x86_64-ninja mingw-w64-x86_64-make # 安装调试器 pacman -S mingw-w64-x86_64-gdb这几条命令的逻辑是先滚动更新 MSYS2 自身再从 mingw64 仓库拉取针对 x86_64-w64-mingw32 目标编译好的工具链。注意包名前缀mingw-w64-x86_64-不能省它决定了你装的是 64 位目标工具链而不是 MSYS 环境下的本地工具。装完后需要把C:\msys64\mingw64\bin加入系统 PATH而不是C:\msys64\usr\bin。这两个目录混了是新手最常见的翻车点usr\bin下的是 MSYS 环境工具编译出来的是依赖 msys-2.0.dll 的程序拿到没装 MSYS2 的机器上直接跑不了。用 w64devkit 的话更简单下载压缩包解压到任意目录把bin目录加入 PATH 即可。验证安装是否成功gcc --version g --version where gccwhere gcc的输出应该指向你刚加入 PATH 的那个目录。如果指向了别的路径说明系统里存在多个 GCC优先级冲突了需要调整 PATH 顺序。2.3 第一个可执行文件编译、链接与运行库模式装好之后先写一个最小程序验证工具链// hello.c #include stdio.h int main(void) { printf(MinGW-w64 Win64 build OK\n); return 0; }编译命令# 动态链接方式默认行为 gcc hello.c -o hello.exe # 静态链接 libgcc 和 libstdc gcc hello.c -o hello_static.exe -static-libgcc -static # 查看依赖的 DLL objdump -p hello.exe | findstr DLL Name第一条命令生成动态链接版本exe 体积小但依赖 libgcc_s_seh-1.dll 等运行库。第二条命令加上-static-libgcc -static后运行库被静态编入 exe体积变大但可以独立分发。第三条命令用 objdump 查看 PE 导入表能直观看到这个 exe 到底依赖哪些 DLL。参数说明-static-libgcc只静态链接 GCC 运行库-static会尝试静态链接所有可用的库包括 libstdc 和 winpthread。如果你用了 posix 线程模型又加了-staticpthread 相关代码也会被静态链入。提示不要用-static去链接系统 DLL 如 kernel32、user32这些永远走动态链接静态链接选项对它们无效。3. 用 CMake 驱动 MinGW for Win64从工具链文件到可分发产物3.1 工具链文件怎么写才不翻车CMake 默认在 Windows 上会去找 Visual Studio 或 MSVC 的编译器你要让它用 MinGW-w64最干净的方式是写一个工具链文件而不是靠命令行传一堆变量。工具链文件在CMAKE_TOOLCHAIN_FILE指定CMake 在配置阶段最开始就会读取它。# mingw-w64-x86_64.cmake set(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86_64) # 指定交叉编译器前缀如果是原生编译可以省略前缀 set(CMAKE_C_COMPILER x86_64-w64-mingw32-gcc) set(CMAKE_CXX_COMPILER x86_64-w64-mingw32-g) set(CMAKE_RC_COMPILER x86_64-w64-mingw32-windres) # 指定目标环境根目录防止 CMake 误用宿主机的库 set(CMAKE_FIND_ROOT_PATH /usr/x86_64-w64-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)这个文件的逻辑是先声明目标系统是 Windows、处理器是 x86_64然后指定 C/C/资源编译器。CMAKE_FIND_ROOT_PATH告诉 CMake 去哪里找目标平台的库和头文件后面三个 MODE 变量控制查找策略——程序在宿主机找库和头文件只在目标根目录找。如果你在 MSYS2 环境里做原生编译编译器名可以写成gcc和g不需要前缀如果你在 Linux 上交叉编译到 Win64前缀就必须写全。配置和构建命令cmake -B build -G Ninja \ -DCMAKE_TOOLCHAIN_FILEmingw-w64-x86_64.cmake \ -DCMAKE_BUILD_TYPERelease cmake --build build-G Ninja指定用 Ninja 作为生成器比 MinGW Makefiles 快不少。-DCMAKE_BUILD_TYPERelease开启优化并去掉调试符号。如果你不指定构建类型CMake 默认是空配置优化等级为-O0产物性能会差很多。3.2 让产物可分发静态链接与 DLL 依赖收集CMake 项目里控制静态链接不要在每个 target 上手动加 flag而是用全局变量或 target 属性# 方式一全局设置影响所有 target set(CMAKE_EXE_LINKER_FLAGS ${CMAKE_EXE_LINKER_FLAGS} -static-libgcc -static-libstdc) # 方式二针对单个 target add_executable(myapp main.cpp) target_link_options(myapp PRIVATE -static-libgcc -static-libstdc)方式一适合整个项目统一策略方式二适合只有部分 target 需要独立分发。注意-static-libstdc和-static的区别前者只静态链接 C 标准库后者会尝试静态链接所有库。如果你的项目依赖了第三方动态库用-static可能导致链接失败或行为异常这时候应该只静态链接 GCC 运行库第三方库单独处理。构建完成后用objdump或ntldd检查依赖# 列出所有导入的 DLL objdump -p build/myapp.exe | findstr DLL Name # 如果有 ntldd 工具直接看依赖树 ntldd -R build/myapp.exe如果输出里还有libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll说明静态链接没生效。检查你的链接选项是否加在了正确的 target 上以及是否被后面的选项覆盖了。CMake 里链接选项的顺序很重要后面的会覆盖前面的同名选项。3.3 和 MSVC 产物的互操作边界msvc 和 mingw 区别是热搜里的高频问题。两者编译出的 C 产物在二进制层面不兼容异常处理机制不同、名称修饰规则不同、标准库 ABI 不同。这意味着你不能在一个 MSVC 编译的 exe 里直接链接 MinGW 编译的 C 静态库反之亦然。但纯 C 接口是可以互操作的因为 C 没有名称修饰和异常传播问题。如果你必须混用常见做法是把 MinGW 侧的功能封装成纯 C 接口的动态库导出extern C函数MSVC 侧通过LoadLibraryGetProcAddress动态加载或者用导入库链接。不要试图直接链接 C 符号那是一条血泪之路。另外MinGW 和 MSVC 对struct默认对齐、wchar_t大小MinGW 默认 2 字节MSVC 也是 2 字节但某些编译选项下会变的处理需要逐一确认跨边界传递结构体时最好用固定宽度的整型和显式 packing。4. 避坑与排查MinGW for Win64 最常见的五类翻车4.1 编译通过但运行报缺少 DLL现象exe 在开发机运行正常复制到其他机器提示缺少libgcc_s_seh-1.dll或libstdc-6.dll。原因默认动态链接 GCC 运行库而这些 DLL 不在目标机器的 PATH 里。解决编译时加-static-libgcc -static-libstdc或者把对应的 DLL 和 exe 放在同一目录。用objdump -p确认依赖列表逐个核对。如果用了 posix 线程模型还要处理libwinpthread-1.dll。4.2 PATH 里混入了 MSYS 的 usr/bin现象编译成功但生成的 exe 依赖msys-2.0.dll在没装 MSYS2 的机器上无法运行。原因PATH 中C:\msys64\usr\bin排在C:\msys64\mingw64\bin前面gcc解析到了 MSYS 环境下的版本。解决调整 PATH 顺序确保mingw64\bin在前。用where gcc确认实际调用的编译器路径。更彻底的做法是不要在系统 PATH 里加usr\bin只在 MSYS2 终端里用。4.3 CMake 找到了错误的编译器现象cmake -B build后生成的构建系统用的是 MSVC 或 clang不是 MinGW-w64。原因没有指定工具链文件CMake 按默认优先级选了 Visual Studio 生成器。解决显式传-DCMAKE_TOOLCHAIN_FILEmingw-w64-x86_64.cmake并且清理 build 目录重新配置。CMake 会缓存编译器路径改工具链文件后必须删掉CMakeCache.txt或整个 build 目录。4.4 静态链接后程序体积暴涨或链接失败现象加了-static后 exe 从几百 KB 变成十几 MB或者链接阶段报未定义符号。原因-static会尝试静态链接所有库包括一些只提供动态版本的第三方库导致链接失败体积暴涨是因为把整个 libstdc 和 libgcc 都链进去了。解决优先用-static-libgcc -static-libstdc而不是-static。如果第三方库只有动态版本就让它保持动态只静态链接 GCC 运行库。体积敏感的场景可以加-Os优化体积或者用strip去掉符号表。4.5 调试信息格式不匹配导致 GDB 无法断点现象GDB 加载 exe 后能运行但断点设不上或者堆栈信息乱码。原因编译时没有加-g或者调试信息格式和 GDB 期望的不一致。MinGW-w64 在 64 位下默认用 DWARF 调试信息但某些发行版可能配置成了别的格式。解决编译时显式加-g -gdwarf-4确保调试信息格式明确。CMake 里设置CMAKE_BUILD_TYPEDebug或RelWithDebInfo。如果还是不行检查 GDB 版本是否和 GCC 版本匹配老版本 GDB 读新格式 DWARF 会出问题。5. 进阶技巧用 MinGW for Win64 做 Qt 与第三方库的交叉构建5.1 Qt 项目用 MinGW 工具链的配置要点Qt 官方为 Windows 提供的预编译包分 MSVC 和 MinGW 两个版本你下载的 Qt 版本必须和工具链匹配。如果你用 MinGW-w64 8.1.0就下载对应 MinGW 8.1.0 的 Qt 包版本号对不上会在链接阶段报 ABI 不兼容。CMake 里配置 Qt 项目时CMAKE_PREFIX_PATH指向 Qt 安装目录下的lib/cmake父目录cmake -B build -G Ninja \ -DCMAKE_TOOLCHAIN_FILEmingw-w64-x86_64.cmake \ -DCMAKE_PREFIX_PATHC:/Qt/6.5.0/mingw_64 \ -DCMAKE_BUILD_TYPEReleaseCMAKE_PREFIX_PATH告诉 CMake 去哪里找 Qt 的配置文件。路径里的mingw_64是 Qt 为 MinGW 64 位准备的目录不要指向msvc2019_64。构建完成后Qt 的 DLL 需要手动复制到 exe 同目录或者用windeployqt工具自动收集windeployqt --release --no-translations build/myapp.exe--release指定收集 Release 版 DLL--no-translations跳过翻译文件。这个命令会把 Qt 核心 DLL、平台插件、样式插件都复制到 exe 旁边生成一个可直接分发的目录。5.2 第三方库的交叉编译与 pkg-config 配置很多第三方库不提供 MinGW 预编译包需要自己编译。以 zlib 为例用 MinGW-w64 编译静态库# 在 MSYS2 MINGW64 终端中 cd zlib-1.3 make -f win32/Makefile.gcc \ PREFIXx86_64-w64-mingw32- \ BINARY_PATH/mingw64/bin \ INCLUDE_PATH/mingw64/include \ LIBRARY_PATH/mingw64/lib \ install参数说明PREFIX指定交叉编译器前缀BINARY_PATH、INCLUDE_PATH、LIBRARY_PATH分别指定安装位置。装完后在 CMake 里用find_package(ZLIB REQUIRED)就能找到。如果库没有提供 CMake 配置文件可以用pkg-config# 设置 pkg-config 搜索路径 export PKG_CONFIG_PATH/mingw64/lib/pkgconfig:$PKG_CONFIG_PATH # 查询编译和链接选项 pkg-config --cflags --libs zlibCMake 里用PkgConfig模块find_package(PkgConfig REQUIRED) pkg_check_modules(ZLIB REQUIRED zlib) target_include_directories(myapp PRIVATE ${ZLIB_INCLUDE_DIRS}) target_link_libraries(myapp PRIVATE ${ZLIB_LIBRARIES})这套流程的关键是确保PKG_CONFIG_PATH指向 MinGW-w64 的 pkgconfig 目录而不是 MSYS 的。路径混了会拿到错误的编译选项链接阶段报架构不匹配。5.3 验证产物可移植性的检查清单在把 exe 发给别人之前我习惯做三个检查。第一用objdump -p列出所有 DLL 依赖确认没有 MSYS 相关 DLL。第二在一台没装 MinGW 和 MSYS2 的干净 Windows 虚拟机上双击运行确认不报缺库。第三如果用了 Qt用windeployqt收集依赖后把整个目录复制到干净机器上再测一次。这三个检查能拦住九成以上的分发翻车。还有一个容易被忽略的点Windows 的 UCRT 和 MSVCRT 运行库差异。MinGW-w64 可以链接到msvcrt.dll老式或ucrtbase.dll现代。如果你的目标机器是 Windows 10 及以上建议用 UCRT 版本的工具链对 C99/C11 的支持更完整。检查方法是在 MSYS2 里看包名mingw-w64-x86_64-gcc默认链接 MSVCRTmingw-w64-ucrt-x86_64-gcc链接 UCRT。两者不能混用选定了就统一到底。我自己的习惯是项目一开始就锁定 UCRT posix 线程 SEH 异常这个组合工具链文件里写死CI 里用同一套环境构建。这样从开发到分发运行库依赖始终一致不会出现「我机器上好好的」这种玄学问题。希望帮到你。本文还有配套的精品资源点击获取