简介面向 Windows 下 C 开发者的 MinGW-w64 工具链发行包版本为 13.2.0采用 posix 线程模型与 seh 异常处理并链接 msvcrt 运行库适合需要跨平台编译或追求轻量级 GNU 环境的开发者使用。压缩包共 2000 个文件总大小约 82.03MB其中以 903 个 .h/.hpp 头文件为主另有 823 个 Python 辅助脚本、少量 .c 源文件、shell 脚本及文档头文件覆盖标准库、C 模板与底层平台接口Python 脚本多用于自动配置与构建辅助便于直接解析和复用。已有 471 人学习下载解压后可获得 bin、include、lib 等完整目录结构包含 gcc/g 编译器、链接器、调试相关工具及 x86_64 专用静态库与动态库对希望复用 Linux 开发习惯、在 Windows 上编译原生 C 程序或维护跨平台项目的开发者来说是一套开箱即用、结构清晰且可直接落入工程实践的完整资源。1. 认识 x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev1.7z这不是普通的压缩包而是一条完整工具链看到x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev1.7z这个文件名第一反应是这是一份可以直接解压使用的 MinGW-w64 交叉工具链压缩包里面装着 GCC 13.2.0 的编译器、链接器、头文件和库文件。它解决的核心问题只有一个在 Windows 上编译出运行在 Windows 上的原生 x86_64 程序而不需要装 Visual Studio 或碰 MSVC 的闭源依赖。适合谁想用 GCC 语法、Clang 习惯、CMake 生态又不想被 MSVC 工程文件绑死的 C/C 开发者尤其是做 Qt、SDL、FFmpeg 绑定或 GNU 风格命令行工具移植的人。这段命名里没有一个是多余的架构、版本、线程模型、异常模型、CRT 绑定、构建修订全部写在了文件名里。很多人下载后直接解压就进坑是因为没看后半段posix-seh-msvcrt的含义结果编译出的程序在别人机器上缺 DLL或者链接时出现奇怪的符号冲突。下面从文件名里的每个字段拆起讲清楚它选了什么、放弃了什么再带你把一条能用的编译链搭起来。2. 拆解文件名x86_64、posix、seh、msvcrt、rt_v11 分别替你做了哪些决定这个文件名是一套完整的工具链约定。理解它的最佳方式不是把它当成一串随机字符而是当成一台编译器的身份证。每一个字段都对应一组编译参数和 ABI 约束改掉任何一环产物的行为都可能变。这一章会把你作为使用者必须知道的几个决定逐个说透。2.1 x86_64 与 13.2.0目标架构和编译器版本x86_64指目标 CPU 架构是 AMD64 / Intel 64 的 64 位指令集不是 i686。这意味着编译器默认生成 64 位目标代码可寻址空间、寄存器宽度、调用约定都遵守 x86_64 ABI。你可以在编译时加-m32尝试生成 32 位代码但 MinGW-w64 的 x86_64 头文件库主要针对 64 位优化除非有特殊兼容需求否则不要这么做。13.2.0是 GCC 的版本号。13.2 是 2023 年的稳定版本支持 C23 的大部分特性和 C11 的默认模式。这个版本不是越新越好因为它对应的 MinGW-w64 运行时版本rt_v11决定了一组配套的winpthreads、libgcc和libstdc库版本。实际编译项目时版本不一致会导致链接器警告比如libstdc.dll.a里的符号版本和头文件声明对不上。2.2 posix 线程模型为什么不是 win32posix指线程模型使用的是 POSIX 线程接口也就是你的代码里可以写pthread_create、pthread_mutex_lock。MinGW-w64 的官方构建通常提供posix和win32两个变体posix带 winpthreads 封装支持 C11 的std::thread、std::mutex和大部分std::async行为win32变体直接用 Windows 线程 API更轻量但很多 C 标准库的并发特性会失效写std::thread会编译报错或运行时不完整。选择口诀是用 C11 并发特性就选 posix只写纯 C 且不需要线程就选 win32 也不会有大问题。但很多知名库头文件里会检测_WIN32_THREADS和_WIN32_WINNT如果你用了 win32 线程模型却在代码里#include condition_variable得到的可能是一段无法链接的代码。我一般直接选 posix虽然会多几个 DLL 依赖但换来了标准兼容。2.3 seh 异常处理与 sjlj 和 dwarf 的取舍seh表示使用 Windows 的Structured Exception Handling来展开 C 异常。GCC 在 Windows 上有三种异常模型dwarf、sjlj和seh。dwarf只在 32 位下可用依赖调试信息展开异常性能好但跨 DLL 会出问题sjlj用setjmp/longjmp保存展开状态兼容所有情况但性能差seh是 64 位 Windows 的原生方案异常处理消耗固定且和 Windows 上 C 异常可以交互。对于x86_64目标MinGW-w64 几乎只提供seh和sjlj两个选项。seh不能用于 32 位sjlj可以同时用在 32/64 位。如果你需要异常穿过 C 边界或与 MSVC 编译的 DLL 互操作seh是唯一靠谱的选择因为它使用 Windows 系统级的展开机制。代价是你不能在异常处理代码里使用某些内建函数如__builtin_eh_return不过一般项目根本碰不到。2.4 msvcrt 运行时CRT 的绑定和兼容边界msvcrt是 MinGW-w64 链接的 C 运行时库具体指msvcrt.dll——Windows 自带的旧版 CRT。这个选择的含义是你的程序不会依赖ucrtbase.dll或vcruntime140.dll这些是 Visual Studio 2015 之后的 UCRT 方案而是使用 Windows 98 以来就存在的老牌 CRT。GCC 的libgcc和libstdc在构建时按msvcrt的符号导出表进行链接因此产生的可执行文件能在没有安装任何运行库的 Windows 系统上跑。但兼容性永远有价msvcrt对 C99 的支持非常有限snprintf在早期版本里是_snprintf并且不保证终止符strtod的浮点解析也有历史问题。MinGW-w64 自己在头文件里做了大量兼容处理但你在写代码时还是要小心比如不要依赖%lld的格式化输出在老 CRT 上的行为。如果项目需要 UCRT 的功能比如__STDC_LIB_EXT1__就要换ucrt变体而不是这个msvcrt包。2.5 rt_v11 与 rev1构建修订和版本配对rt_v11指的是 MinGW-w64 运行时runtime的版本号对应mingw-w64的某个 release 或 snapshot。它决定了一组头文件、导入库和 CRT 内部函数的实现状态。rev1则是这个构建的修订补丁号可能是修复了某个libgcc的链接 bug 或更新了winpthreads的定时器实现。在实际使用中rt_v11和rev1最关键的影响是这个工具链与某些第三方预编译库的 ABI 是否兼容。比如你从 vcpkg 下载的libcurl如果是用另一个 MinGW-w64 版本编译的它们的libgcc和winpthreads版本可能不一致链接时会提示undefined reference或导入库符号不匹配。遇到这种情况最快的解决方法是重新用本工具链源码编译依赖而不是去混用预编译包。这是 MinGW 生态里最常见的玄学问题根源几乎都在版本配对。3. 在 Windows 上安装与配置解压、环境变量和第一条编译命令拿到.7z文件解压本身很简单但要让gcc用得顺手需要处理三个细节路径不带空格、PATH 只加bin、确认动态库能找到。下面几步是从零到能编译的完整操作。3.1 解压到纯英文路径并验证目录结构先安装 7-Zip或直接用自带 tar 的新版 Windows 也支持7z格式但命令不同。解压时一定要指定一个C:\tools\mingw64这样的纯英文路径不要放在带空格或中文的目录否则很多 Makefile 和 CMake 生成器会因空格转义出问题。解压后目录里应该有bin、lib、libexec、include、x86_64-w64-mingw32这几个顶层目录。mkdir C:\tools 7z x x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev1.7z -oC:\tools逻辑说明-o指定输出目录注意它和路径之间没有空格。解压后进入C:\tools\mingw64bin下应该有gcc.exe、g.exe、mingw32-make.exe等文件。x86_64-w64-mingw32目录下存放目标的include和lib因为编译器是交叉性质的——它生成本机代码但使用独立的头文件树。参数说明如果系统里已经装了旧版 MinGW先临时把C:\tools\mingw64\bin放到 PATH 最前面避免gcc指向旧版本。验证时直接运行gcc --version看到gcc (GCC) 13.2.0即成功。另外确认bin下有libgcc_s_seh-1.dll和libwinpthread-1.dll这俩是编译 posix 线程加 seh 模型的程序运行时的最低依赖。3.2 设置 PATH 和编译环境变量设置 PATH 有两种方式临时会话用set永久生效用系统设置。我更建议在项目根目录放一个env.bat每次进命令行先执行它避免污染全局环境。set PATHC:\tools\mingw64\bin;%PATH% set CCgcc set CXXg set MSYSTEMMINGW64逻辑说明CC和CXX是 CMake 和很多构建系统识别编译器的环境变量。MSYSTEM是 MSYS2 环境下才需要的变量如果你在纯 cmd 或 PowerShell 下用不是必须但列在这里方便将来在 Git Bash 中使用。注意不要设置LIB和INCLUDE环境变量去强制gcc去找 MSVC 的库那会直接导致冲突。参数说明如果你在 PowerShell 里需要先执行$env:Path C:\tools\mingw64\bin; $env:Path格式不一样。设置完 PATH 后再运行where gcc能显示路径确认没有命中别的编译器。3.3 编译一个 Hello 程序并确认运行时依赖写一个最小的 C 文件用 gcc 编译并运行然后检查可执行文件依赖的动态库。这一步能一次性验证编译器、链接器和 CRT 可用性。// hello.c #include stdio.h #include threads.h #ifdef __MINGW32__ int main(void) { printf(Hello %s\n, __VERSION__); return 0; } #endifgcc -stdc11 -O2 hello.c -o hello.exe -static逻辑说明加了-static把libgcc、libwinpthread都静态链入此时hello.exe只依赖msvcrt.dll它是 Windows 系统自带的。__VERSION__展开成13.2.0通过这个宏可以确认头文件和编译器版本一致。参数说明-stdc11指定 C 标准MinGW-w64 默认的 gnu17 也够用但显式指定能避免某些旧代码在不同 C 标准下的行为差异。-O2是常见优化等级。如果不用-static可以运行ntldd hello.exeMinGW 自带工具查看 DLL 依赖但多数环境没有ntldd可以用where找出动态库路径或直接用 PowerShell 的Get-Command检查。如果运行hello.exe报错缺 DLL回到bin目录看是否有libgcc_s_seh-1.dll和libwinpthread-1.dll。检验办法是假设你写了一段 C 代码用了std::thread编译时没加-static那么运行时必须能在 PATH 中找到这两个 DLL。为了避免发布噩梦我会在 Release 构建时统一加-static-libgcc -static-libstdc。4. 用 CMake MinGW-w64 跑通一个真实项目四个必调的参数到了实际项目没有人直接用 gcc 编译几十个文件。CMake 是关键。但 CMake 和 MinGW-w64 配对的常见坑不少生成器选错、目录带空格、找错编译器、链接时混入 Visual Studio 的库。下面给出一个可复用的最小 CMake 工程配置并解释每个必调参数背后的原因。4.1 指定生成器和工具链前缀CMake 如果默认生成器是 Visual Studio你就会拿到一个.sln而不是 Makefile。用 MinGW-w64 必须是MinGW Makefiles生成器。同时CMake 默认用gcc找编译器等但为了防止系统里存在多个 MinGW 版本最好在命令行直接指定编译器路径。# CMakeLists.txt cmake_minimum_required(VERSION 3.25) project(mingw_demo C CXX) set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) set(CMAKE_SYSTEM_NAME Windows) add_executable(demo main.cpp)cmake -S . -B build -G MinGW Makefiles ^ -DCMAKE_C_COMPILERC:/tools/mingw64/bin/gcc.exe ^ -DCMAKE_CXX_COMPILERC:/tools/mingw64/bin/g.exe cmake --build build -j8逻辑说明CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY是关键的后悔药。CMake 在配置阶段会尝试一遍编译测试如果目标类型默认是可执行文件它在链接 C 运行时的时候容易因为找不到libstdc而报错设置成STATIC_LIBRARY后测试只生成.o文件不链接从而绕过伪报错。CMAKE_SYSTEM_NAME Windows是告诉 CMake 在 Windows 上构建时遵循 MinGW 约定。参数说明-G MinGW Makefiles必须和CMAKE_MAKE_PROGRAM匹配。如果目录里有mingw32-make.exeCMake 会自动找到但有些只装了 gcc 没装 make 的环境需要额外指定。-j8是并行度按 CPU 核心数调整。4.2 处理库路径和链接顺序项目一旦引入第三方库比如libcurl或zliblink_directories和target_link_libraries的顺序就会决定成败。MinGW 的链接器在解析符号时是单遍扫描库必须放在源文件或目标文件之后。target_include_directories(demo PRIVATE C:/tools/mingw64/x86_64-w64-mingw32/include) target_link_directories(demo PRIVATE C:/tools/mingw64/x86_64-w64-mingw32/lib) target_link_libraries(demo PRIVATE ws2_32 pthread -static-libgcc )逻辑说明ws2_32是 Windows Socket 的导入库很多网络库依赖它。pthread对应 winpthreads 的导入库虽然你在代码里用的是std::thread但底层的winpthreads实现需要显式链接。-static-libgcc不是库名而是链接选项CMake 允许你把编译选项直接写在链接库列表里但更清晰的做法是用target_link_options。参数说明如果target_link_libraries里同时有curl和ssl顺序必须是左侧依赖右侧即curl在ssl前面因为curl的符号引用需要从ssl中解析。这是所有类 Unix 链接器的共性坑Windows 上用 MinGW 一样遵守。如果你把pthread放到了最后而前面的目标文件用了std::thread偶尔也会undefined reference把pthread放到库链末尾通常能解决。4.3 静态链接与动态链接的选择MinGW-w64 的默认行为是优先动态链接libgcc和libstdc。但对发布而言动态链接会让你得到一个需要附带一堆 DLL 的安装包。这就是为什么 Release 配置里应该显式指定静态链接。if(CMAKE_BUILD_TYPE STREQUAL Release) target_link_options(demo PRIVATE -static-libgcc -static-libstdc) endif()逻辑说明-static-libstdc会把整个 C 标准库静态链入加上-static-libgcc后唯一剩下的动态依赖就是 Windows 的msvcrt.dll。代价是产物体积膨胀一个 Qt 级别的程序可能大 5~10MB但对于无需安装运行库的分发场景这是最省心的方案。参数说明CMAKE_BUILD_TYPE必须是Release且不能为空否则这段不生效。如果项目里还用了winpthreads的 DLL 版本需要再加-static完全静态化但这会带来一个隐患静态链接的winpthreads可能与其他 DLL 中的线程接口冲突在混合动态库场景下会崩溃。所以我的习惯是目标 exe 用-static-libgcc -static-libstdc但允许winpthreads动态因为它只影响线程内部实现不会在 C ABI 层造成冲突。4.4 从 VSCode 按 F5 调试gdb 与 MinGW 的配置调试需要 GDB。MinGW-w64 包通常携带gdb.exe但版本可能较旧。配置文件.vscode/launch.json需要指定miDebuggerPath并告诉调试器当前工具链的符号路径。{ version: 0.2.0, configurations: [ { name: MinGW Debug, type: cppdbg, request: launch, program: ${workspaceFolder}/build/demo.exe, args: [], cwd: ${workspaceFolder}, miDebuggerPath: C:/tools/mingw64/bin/gdb.exe, environment: [], externalConsole: true } ] }逻辑说明type必须是cppdbg它依赖 Microsoft C 调试扩展。miDebuggerPath指定 GDB 的绝对路径。用 Seh 模型编译时GDB 需要能够处理 Windows 结构化异常因此 GDB 版本不能太老13.x 以上一般没问题。externalConsole: true会让程序在外部控制台运行避免 VSCode 集成终端在断点时冻结。参数说明如果调试发现断点打不进去检查编译时是否加了-g。CMake Release 模式默认没有调试信息需要改成RelWithDebInfo或手动加-g -O1。另一个常见翻车点是程序用了std::cout但 GDB 在解析 locale 时卡住忽略即可不影响调试。5. 避坑从解压到发布的常见问题排查工具链本身稳定但使用姿势不对会触发一系列看起来像工具链坏了的问题。以下五条来自一线常用场景每一条都是现象、原因、解决三段可以当成排错手册用。5.1 解压报错文件名太长或文件不完整现象解压.7z时提示Filename too long或者解压后bin/gcc.exe缺失x86_64-w64-mingw32/include目录空。原因.7z包内路径很深解压到用户目录导致路径总长度超过 Windows 的 260 字符限制或者使用了 Windows 自带的解压程序它对 7z 的支持不完整。解决终极办法是启用 Windows 10 1607 以上的长路径支持注册表HKLM\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled设为 1然后重启。但更简单的是直接解压到盘符根目录下的短路径比如C:\mingw64路径深度减少了三分之一。如果已经解压失败删除残留目录重新解压别在原目录上覆盖。5.2 编译时找不到stdio.h或cassert现象写个最简单的#include stdio.h都报No such file or directory但gcc能看到。原因编译器按自己的默认目录找头文件但环境变量CPATH或C_INCLUDE_PATH被设成了别的编译器路径例如指向 MSVC 的 include或者用户目录里有.bashrc设置过INCLUDE。解决先清掉自定义的CPATH、INCLUDE、LIB环境变量重启终端再试。然后在gcc命令行加-v参数看输出里的#include ... search starts here后面的路径列表确认C:\tools\mingw64\lib\gcc\x86_64-w64-mingw32\13.2.0\include和C:\tools\mingw64\x86_64-w64-mingw32\include都在其中。如果不在说明 toolchain 目录安装不完整或路径分离。5.3 运行 exe 提示缺少libgcc_s_seh-1.dll或libwinpthread-1.dll现象编译成功后双击 exe 弹窗提示找不到这些 DLL。有时在开发机没事换一台机器就报错。原因开发机的 PATH 里有 MinGW 的bin运行时能自动找到发布到没有 MinGW 的机器后动态依赖暴露出来了。解决最直接的是在构建时加-static-libgcc -static-libstdc但libwinpthread-1.dll仍然动态链接。把它一起静态化的方式是给 Makefile 或 CMake 加-static前提是你确认程序里没有跨 DLL 传递FILE*或 C 对象。如果已经用动态链接生成了 exe也可以用ntldd -R your.exe列出所有依赖然后把对应 DLL 复制到 exe 目录这是快速止血方案。5.4 与 MSVC 编译的 DLL 混用出现 ABI 崩溃现象你的程序调用一个由 MSVC 编译的 DLL比如某些 Windows 系统 API 封装库传结构体进去后程序崩溃或数据错乱但之前的 MinGW 旧版本没这个问题。原因MSVC 和 GCC 的 C ABI 完全不兼容但 C ABI 通常是兼容的。崩溃点在结构体对齐不同版本的 C 编译器对于struct的默认对齐策略一致但如果你在代码里开了#pragma pack或者使用了__declspec(align)两边不一致就会爆炸。解决在头文件里明确使用__cdecl调用约定并在 DLL 接口层用extern C包裹。结构体不允许 STL 类型成员所有字符串传const char*。还有一个血泪经验永远不要用new[]在 DLL 里分配、在 exe 里释放反之亦然老老实实提供alloc/free成对函数。5.5 CMake 配置时提示编译器检测失败现象运行cmake -G MinGW Makefiles时输出里有does not work或Failed to run MSBuild command随后提示KeyError: CMAKE_BINARY_DIR直接退出。原因不是 MinGW-w64 坏了而是 CMake 在调用编译器做try_compile时遇到了缺mingw32-make.exe或路径有空格的问题。CMAKE_TRY_COMPILE_TARGET_TYPE没设置成STATIC_LIBRARY时编译器试图链接一个可执行文件由于缺少libmingw32.a或libgcc的顺序错误失败。解决在CMakeLists.txt顶部写死set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)。同时-DCMAKE_MAKE_PROGRAMC:/tools/mingw64/bin/mingw32-make.exe并确认这个文件存在。如果用的是 Git Bash 里的 CMake路径前缀要转换成 Windows 风格即/c/tools/mingw64/bin/mingw32-make.exe有些 CI 脚本就在这一步翻车。建议永远使用原生 cmd 或 PowerShell 跑 CMake不要在 Bash 里跨界。6. 验证与进阶检查产物依赖把工具链用到 CI 流水线里当你能顺利编译一个项目后离投稿还有两步验证产物真的不依赖陌生 DLL以及让这套工具链在无 GUI 的 CI 环境里重复使用。先讲验证再上一个我常用的 CI 阶段配置思维。验证动态库依赖最简单的方式是用ldd或objdump但 MinGW-w64 自带的ldd其实是脚本不靠谱。这里更实用的是ntldd如果你没有它可以用 PowerShell 的Get-Command配合where.exe人工判断。我一般直接写一个检查脚本把所有动态依赖路径打印出来objdump -p hello.exe | grep DLL Name输出通常是msvcrt.dll、KERNEL32.dll、libwinpthread-1.dll等。其中msvcrt.dll和KERNEL32.dll是系统内置没问题如果出现libgcc_s_seh-1.dll或没见过的第三方 DLL就要用上一章的静态链接方案处理。注意objdump解析的 DLL 名是硬编码在 PE 导入表里的不会考虑 PATH 搜索顺序所以只要列出的名字都能在目标机器系统目录或 exe 旁找到就可以放心分发。进阶用法是把这个工具链塞进 CI。关键点是 CI 无头环境没有交互式终端所以所有路径必须显式。我习惯在.github/workflows或 GitLab CI 里写一个install_toolchain步骤下载.7z后解压到$RUNNER_TEMP然后设置环境变量。这里有一个坑CI 上不要用.7z直接解压带宽和时间都不划算常见做法是本地先转成.zip或者用 CI 自带的 7z 命令。另外CI 上执行 CMake 时会读取PATH你需要把 MinGW 的bin路径加到每个执行步骤的最前面而不是全局env否则可能被系统自带的其他 GCC 干扰。还有一个容易被忽略的验证点把程序拿到一台没有开发工具的干净 Windows 虚拟机或容器里跑一遍。我在发布前会做这个动作屡次救回过漏带 DLL 的事件。如果你是在 GitHub Actions 的windows-latest上跑它自带 Visual StudioPATH 里没有 MinGW你要额外显式设置所有编译器路径。这就是为什么前面的 CMake 命令里要写死CMAKE_C_COMPILER而不是依赖cc。最后聊一个我自己的习惯这套工具链包虽然名叫x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev1但它不是唯一的版本。我会在项目根目录建一个toolchain.txt文件记录这个版本并写清楚为什么选它——比如需要 C thread 所以 posix需要跨 DLL 异常所以 seh需要免安装运行库所以 msvcrt。等下次升到 GCC 14 时我可以直接对照这个文档评估影响。工具链版本是一个和代码库同样重要的技术决策留一份文字记录能省下一整轮排查时间。希望这篇笔记帮你在 Windows 上把这套 MinGW-w64 用得干净利落。本文还有配套的精品资源点击获取