简介这是一份面向 Windows 平台 C/C 开发者的 MinGW-w64 工具链发行包基于 GCC 13.2.0 构建采用 POSIX 线程模型与 SEH 异常处理机制并链接 msvcrt 运行时库适合需要在 Windows 上获得类 GNU/Linux 编译体验、又不愿依赖大型 IDE 的开发者使用。压缩包共收录约 2000 个文件以 903 个 .h 头文件、823 个 .py 脚本、243 个 .hpp 头文件为主另含少量 .c 源码、.txt 说明、.sh 脚本及 .md、.js、.html、.css 等辅助文件整体约 82.03MB。其中头文件与库文件构成完整的编译与链接基础Python 脚本多用于构建、测试与工具链维护目录结构清晰便于按模块检索。资源已有 470 人学习下载适合希望深入理解 MinGW-w64 组成、排查编译链接问题或搭建轻量 C 开发环境的中高级读者参考。1. 拿到 x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev1.7z 先别急着解压如果你在 Windows 上写 C又不想被 Visual Studio 那套工程文件绑死大概率绕不开 MinGW-w64 这套 GNU 工具链。这个压缩包名字长得像乱码其实每个字段都在交代它的身份x86_64 是目标架构13.2.0 是 GCC 版本posix-seh 是线程模型加异常模型msvcrt 是 C 运行时rt_v11-rev1 是运行时库修订号。它解决的核心问题很具体——在 Windows 上给你一套能直接调 g、gcc、gdb 的完整环境编译出来的 exe 不依赖 MinGW 安装目录拷到别的机器上只要有对应 DLL 就能跑。适合谁适合做跨平台 C 库开发、需要复现 Linux 构建行为、或者单纯想用 CMake GCC 而不是 MSVC 的人。不适合谁不适合指望它替代 Visual Studio 调试体验的人也不适合需要 MSVC 专有 ABI 兼容的场景。2. 拆开压缩包目录结构与工具链选型逻辑2.1 解压后先看 mingw64 目录里有什么7z 解压之后根目录通常只有一个 mingw64 文件夹。别急着把它扔进 C 盘某个角落先花两分钟看清楚结构后面配环境变量和排错都靠这个。# 假设解压到 D:\toolchains\mingw64-13.2.0 # 进入根目录看一级结构 cd /d D:\toolchains\mingw64-13.2.0 dir /b # 典型输出 # mingw64再往下走一层cd mingw64 dir /b # bin # etc # include # lib # libexec # opt # share # x86_64-w64-mingw32这几个目录的分工直接决定你后面怎么配路径目录作用你什么时候会碰它bing.exe、gcc.exe、gdb.exe、mingw32-make.exe配 PATH 时第一个加的就是它includeC 标准库头文件、部分系统头文件编译报 “找不到 xxx.h” 时来这查lib静态库 .a、导入库 .dll.a链接报 undefined reference 时来这翻x86_64-w64-mingw32目标平台专属的 include 和 lib交叉编译或指定 sysroot 时用libexeccc1plus.exe 等编译器后端一般不动但报 internal compiler error 时要看share文档、locale基本不碰你项目正文里列的那些文件——xxmodule.c、tkAppInit.c、config.c、_pydoc.css、sqlite3.h、avx512fintrin.h、avx512vlintrin.h、bfd.h、obj_mac.h、stl_algo.h——正好对应了这套工具链的几个关键面。sqlite3.h 在 include 下说明自带 SQLite 开发头avx512fintrin.h 和 avx512vlintrin.h 是 GCC 的 AVX-512 内建函数头意味着 13.2.0 这版对 AVX-512 指令集有完整支持bfd.h 是 binutils 的二进制文件描述符头gdb 和 objdump 都靠它obj_mac.h 是 OpenSSL 的对象标识符头stl_algo.h 是 libstdc 的算法实现头。这些文件同时出现说明这不是一个精简版而是带完整开发头文件和 binutils 的发行版。2.2 为什么选 posix-seh 而不是 win32-sjlj这是整个包名里最值得展开的一段。MinGW-w64 的线程模型和异常模型是两个独立维度组合起来有四种常见搭配win32 sjlj最老最稳但 sjlj 异常处理有性能开销且不支持 64 位下的结构化异常win32 sehSEH 异常性能好但线程模型是 Windows 原生std::thread 行为跟 Linux 有差异posix sjljPOSIX 线程 sjlj 异常跨平台线程行为好但异常慢posix sehPOSIX 线程 SEH 异常兼顾跨平台线程语义和异常性能你手里这个包是 posix-seh意味着 std::thread、std::mutex、std::condition_variable 这些走的是 POSIX 线程模拟层行为更接近 Linux 上的 libstdc。如果你写的代码里用了 std::thread 并且期望它在 Windows 和 Linux 上表现一致posix 线程模型是必须的。SEH 则让 try/catch 和栈展开在 x86_64 上走硬件异常机制比 sjlj 快一个数量级。常见做法是做跨平台服务端或中间件选 posix-seh只做 Windows 原生小工具win32-seh 也行。但既然包名已经定了 posix-seh你不需要再纠结直接用。2.3 msvcrt 和 rt_v11 到底影响什么msvcrt 指的是链接 Microsoft Visual C 运行时库的旧版接口msvcrt.dll而不是 UCRTUniversal C Runtime。这个选择的影响很实际用 msvcrt 编译出的 exe在 Windows 7 到 Windows 11 上都能跑因为 msvcrt.dll 是系统自带的用 UCRT 的话Windows 10 以下需要额外装 Universal CRT 更新但 msvcrt 对 C99/C11 的一些新函数支持不如 UCRT 完整比如某些宽字符和 locale 相关函数rt_v11 是运行时库版本号rev1 是修订版。这个字段你平时不用管但如果你从别的渠道下了一个 rt_v10 的包混用 lib 目录下的 .a 文件链接时可能报符号冲突。血泪经验是一个项目只用一套 MinGW别把不同 rt 版本的库混着链。3. 配环境与编译第一个 C 程序从 PATH 到 CMake3.1 把 bin 加进 PATH 并验证版本解压完第一件事不是写代码是让命令行能找到 g。我一般不改系统 PATH而是在项目根目录放一个 setenv.bat每次开终端先跑它。:: setenv.bat echo off set MINGW_HOMED:\toolchains\mingw64-13.2.0\mingw64 set PATH%MINGW_HOME%\bin;%PATH% echo MinGW-w64 13.2.0 environment ready. g --version跑完你应该看到类似g (x86_64-posix-seh-rev1, Built by MinGW-W64 project) 13.2.0 Copyright (C) 2023 Free Software Foundation, Inc.如果报 “不是内部或外部命令”检查两点路径里有没有空格有空格要加引号以及 bin 目录下是不是真的有 g.exe。有时候杀毒软件会把新解压的 exe 隔离翻车过好几次。3.2 编译一个带 std::thread 的程序验证 posix 线程模型光看版本号不够得写个真正用到 posix 线程特性的程序确认这套工具链的线程模型是对的。// thread_check.cpp #include iostream #include thread #include mutex #include vector std::mutex mtx; void worker(int id) { std::lock_guardstd::mutex lock(mtx); std::cout thread id id std::this_thread::get_id() std::endl; } int main() { std::vectorstd::thread pool; for (int i 0; i 4; i) { pool.emplace_back(worker, i); } for (auto t : pool) { t.join(); } std::cout main thread id std::this_thread::get_id() std::endl; return 0; }编译命令g -stdc17 -O2 -pthread thread_check.cpp -o thread_check.exe参数说明-stdc17 指定标准-O2 开优化-pthread 是关键——posix 线程模型下必须加这个否则 std::thread 链接会报 undefined reference to_imp__pthread_create。运行后如果四个线程 ID 各不相同且主线程 ID 也不一样说明 posix 线程层工作正常。3.3 用 CMake 组织一个多文件项目单文件编译只是热身真实项目一般用 CMake。MinGW-w64 配 CMake 的常见做法是生成 MinGW Makefiles。# CMakeLists.txt cmake_minimum_required(VERSION 3.20) project(demo LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) add_executable(demo src/main.cpp src/config.c ) target_include_directories(demo PRIVATE ${CMAKE_SOURCE_DIR}/include ) target_link_libraries(demo PRIVATE sqlite3 ws2_32 )配置和构建mkdir build cd build cmake -G MinGW Makefiles -DCMAKE_BUILD_TYPERelease .. mingw32-make -j8这里有几个参数值得说-G MinGW Makefiles 告诉 CMake 用 mingw32-make 而不是 nmake-DCMAKE_BUILD_TYPERelease 在 MinGW 下会映射到 -O3 -DNDEBUG-j8 是并行编译核数按你 CPU 来。链接 ws2_32 是因为 Windows 下 socket 相关符号在这个库里如果你代码里用了网络功能不加就报 undefined reference toWSAStartup。注意CMake 在 MinGW 下默认找的编译器就是 PATH 里第一个 g如果你系统里还有别的 GCC比如 MSYS2 的先跑where g确认顺序。4. 头文件与库的排查从 sqlite3.h 到 avx512fintrin.h4.1 编译报 “找不到 sqlite3.h” 时怎么定位你项目正文里列了 sqlite3.h说明这个包自带 SQLite 开发头。但如果你 include 之后报找不到按这个顺序查# 第一步确认头文件在不在 dir /s /b %MINGW_HOME%\include\sqlite3.h # 第二步确认编译器实际搜索路径 echo | g -E -x c - -v 21 | findstr /i include # 第三步如果头文件在但找不到手动加 -I g -I%MINGW_HOME%\include -c mydb.cpp -o mydb.o常见原因是你的项目里用了#include sqlite3.h但编译器搜索路径没包含 MinGW 的 include。另一种情况是你从别处下了一个 sqlite3.h 放在项目目录版本跟 lib 里的 sqlite3.a 不匹配链接时报符号缺失。我一般会统一用工具链自带的头避免版本漂移。4.2 avx512fintrin.h 和 avx512vlintrin.h 怎么用这两个头是 GCC 提供的 AVX-512 内建函数接口。avx512fintrin.h 对应 AVX-512 Foundation 指令集avx512vlintrin.h 对应 Vector Length 扩展。要用它们编译时必须开对应的 -march 或 -mavx512 开关。// avx512_demo.cpp #include immintrin.h #include cstdio int main() { // 用 AVX-512F 做 16 个 float 的加法 __m512 a _mm512_set1_ps(1.0f); __m512 b _mm512_set1_ps(2.0f); __m512 c _mm512_add_ps(a, b); float out[16]; _mm512_storeu_ps(out, c); printf(out[0]%f out[15]%f\n, out[0], out[15]); return 0; }编译g -stdc17 -O2 -mavx512f -mavx512vl avx512_demo.cpp -o avx512_demo.exe参数说明-mavx512f 启用 Foundation 指令-mavx512vl 启用 VL 扩展。如果你的 CPU 不支持 AVX-512编译能过但运行会非法指令崩溃。先跑wmic cpu get name确认型号或者用gcc -marchnative -Q --helptarget | findstr avx512看编译器探测结果。注意AVX-512 在部分 Intel 消费级 CPU 上被屏蔽编译前先确认硬件支持别写完代码才发现跑不了。4.3 bfd.h 和 obj_mac.h 的典型使用场景bfd.h 是 binutils 的 BFD 库头文件一般你不会直接 include 它除非你在写自己的调试器或二进制分析工具。obj_mac.h 是 OpenSSL 的 OID 定义头如果你用 OpenSSL 做证书解析会间接用到。这两个头出现在包里说明这个 MinGW 发行版带了 binutils 开发文件和 OpenSSL 头不是精简版。如果你确实要链 BFDg -stdc17 bfd_tool.cpp -o bfd_tool.exe -lbfd -liberty -lz常见坑是 -lbfd 依赖 -liberty 和 -lz顺序不能反否则报 undefined reference。链接器从左到右解析被依赖的库放右边。5. 避坑与常见问题那些让我重装三次的坑5.1 编译通过但运行报 “找不到 libgcc_s_seh-1.dll”现象exe 在你自己机器上跑得好好的拷到同事电脑上双击就弹窗缺 DLL。原因MinGW 默认动态链接 libgcc 和 libstdc这些 DLL 在 mingw64\bin 下但目标机器没有。解决要么把对应 DLL 一起拷过去要么静态链接。静态链接加-static-libgcc -static-libstdc如果还用了 posix 线程再加-static全静态。但全静态会让 exe 变大且某些库不支持静态链接。g -stdc17 -O2 -static-libgcc -static-libstdc -pthread main.cpp -o main.exe5.2 CMake 报 “CMAKE_CXX_COMPILER not set”现象跑 cmake -G MinGW Makefiles 时提示找不到编译器。原因PATH 里没有 g或者 CMake 缓存了上一次的编译器路径。解决先确认g --version能跑然后删掉 build 目录重新来。如果还不行显式指定cmake -G MinGW Makefiles -DCMAKE_CXX_COMPILERg -DCMAKE_C_COMPILERgcc ..5.3 链接时报 “undefined reference to__imp_xxx”现象编译过了链接一堆 undefined reference符号名带 _imp前缀。原因这是 Windows 导入库的符号命名方式说明你用了某个 DLL 的函数但没链对应的 .dll.a 导入库。解决找到函数所属的库加 -l 参数。比如 WSAStartup 在 ws2_32CreateThread 在 kernel32。用nm在 lib 目录下搜nm -A %MINGW_HOME%\x86_64-w64-mingw32\lib\*.a | findstr WSAStartup5.4 posix 线程模型下 std::thread 编译报错现象不加 -pthread 时std::thread 相关符号全部 undefined。原因posix 线程模型的 pthread 实现放在 libwinpthread.a需要显式链接。解决编译和链接都加 -pthread。CMake 里用find_package(Threads REQUIRED)然后target_link_libraries(demo PRIVATE Threads::Threads)它会自动处理。5.5 混用不同 rt 版本的库导致符号冲突现象链接时报 multiple definition 或者符号版本不匹配。原因你从 A 包拿了 libfoo.a从 B 包拿了 libbar.a两个包的 rt 版本不同底层运行时符号冲突。解决一个项目只用一套 MinGW。如果必须用第三方预编译库确认它用的运行时版本跟你一致。实在不行用objdump -p看 DLL 依赖或者重新从源码编译第三方库。6. 进阶用这套工具链做静态分析与交叉验证6.1 用 gdb 做崩溃现场分析MinGW-w64 自带 gdb但默认没有调试符号。编译时加 -g崩溃后能直接看栈。g -stdc17 -g -O0 -pthread crash_demo.cpp -o crash_demo.exe gdb crash_demo.exe进 gdb 后(gdb) run # 崩溃后 (gdb) bt full (gdb) info threads (gdb) thread apply all btbt full 会打印局部变量info threads 看所有线程状态。posix 线程模型下 gdb 对线程的识别比 win32 模型好这也是选 posix 的一个隐藏好处。6.2 用 -fsanitize 做运行时检查GCC 13 在 MinGW 下支持部分 sanitizer。AddressSanitizer 和 UndefinedBehaviorSanitizer 可用ThreadSanitizer 在 Windows 上支持有限。g -stdc17 -g -fsanitizeaddress,undefined -fno-omit-frame-pointer mem_check.cpp -o mem_check.exe跑的时候如果报 heap-buffer-overflow会直接打印分配和释放的栈。注意 sanitizer 需要链接对应的运行时库MinGW 包里一般带了 libasan 和 libubsan如果没有去 lib 目录确认。6.3 验证编译产物是否真的不依赖 MinGW 目录一个实用技巧用 objdump 看 exe 的 DLL 依赖确认没有指向你本地路径的绝对引用。objdump -p main.exe | findstr DLL Name正常输出应该只包含系统 DLL 和你主动链接的第三方 DLL不应该出现 D:\toolchains... 这种路径。如果出现了说明某个库被动态链接到了本地路径换机器必挂。我一般会在发布前强制走一遍这个检查再加上where g确认工具链来源两个都过了才敢把 exe 交出去。从那以后每次换新 MinGW 包我都先跑一个最小 posix 线程程序加 objdump 检查确认没问题再往项目里迁。希望帮到你。本文还有配套的精品资源点击获取
