★ FEATURED ARTICLE 简介这份离线安装包面向需要在64位Windows上搭建原生C/C开发环境的程序员与学习者核心是GCC 13.1.0正式稳定版采用posix线程模型、SEH结构化异常处理与ucrt统一C运行时库无需联网即可一次性完成部署适合网络受限或希望固定工具链版本的项目场景。压缩包为7z格式约68.89MB内含18725个文件以html文档、h头文件、a静态库、hpp模板头、py脚本与少量exe可执行程序为主另有tcl终端配置、dll动态库、txt说明等解压后呈现bin、lib、include等标准目录便于按需检索。目前已有1649人学习下载。读者可直接获得gcc、g编译器、链接器、标准库与头文件的完整组合覆盖C与C的编译、链接与调试链路并支持对C20/23新特性的尝鲜验证固定版本的工具链也有助于复现旧项目构建结果、排查编译差异是Windows下跨平台开发与原生64位应用构建的实用基础环境。1. 一个版本字符串引发的翻车为什么我坚持用 x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r 离线包上周帮一个同事收拾构建环境项目 clone 下来cmake一跑就报找不到编译器他翻出电脑里躺了两年的 MinGW解压、加环境变量gcc -v倒是能出版本号结果一编译就死在std::filesystem上又换了个包链接阶段报_Unwind_Resume未定义。折腾一下午最后换成本文要讲的这个x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r离线包五分钟跑通。这套环境在 Windows 上做 C/C 开发太常见了常见到很多人以为「解压即用」可版本线程模型选错、运行库选错就会出现编译能过链接炸、链接能过运行炸的玄学现象。这篇笔记写给正在 Windows 上配 GCC 工具链的人不管你是第一次装 MinGW-w64还是被旧环境坑过想重装一套干净的照着走一遍就行。2. 拆解安装包x86-64、posix、seh、ucrt 各自管什么动手之前先把名字读懂这一串不是随机生成的每一位都对应一个编译期或运行期的决定选错了后面 all 是白费功夫。离线包的好处是不依赖网络解压即得适合内网机器、老笔记本和不想被下载中断打断的场景。2.1 版本号与目标架构x86-64 与 13.1.0 的取舍x86-64指目标架构是 64 位 Windows产出的是 PE32 格式的可执行文件。如果你的项目还要编 32 位程序那是另一套i686包的事别指望一个包通吃。13.1.0是 GCC 的主版本号这个版本对 C20 的 ranges、concepts 支持已经相当完整C23 的部分特性也有了实验性支持比 8.x、9.x 那批老包在标准库实现上干净很多。我一般不建议追最新的大版本也不建议用太老的。新版本刚出时生态适配没跟上某些第三方库的头文件会和新标准库打架太老的版本又会卡在std::format、bit这类头文件缺失上。13.1.0 属于比较稳的中间点。安装前建议先确认本机情况用 PowerShell 跑一下# 确认系统架构与已存在的编译器 [Environment]::Is64BitOperatingSystem where.exe gcc where.exe g where.exe mingw32-make第一条返回True才能用 x86-64 包。后三条如果输出了路径,说明系统里已经有别的 MinGW 或 MSYS2、Cygwin 提供的 gcc这是后面很多怪问题的源头——多个工具链抢 PATH一定要先记下这些路径装完新包后把它们从 PATH 里清掉或者干脆调整优先级。2.2 线程模型 posix 与异常模型 seh两个最容易选错的参数posix是线程模型。它决定了 libstdc 里std::thread、std::mutex、std::condition_variable这些设施底层接的是哪套线程实现。Windows 上还有另一种叫win32的线程模型好处是不依赖额外的运行时 DLL坏处是对 C11 线程库的支持残缺很多依赖std::thread的代码在 win32 模型下直接编译失败或行为异常。只要你的项目用了标准库线程就选posix没有例外。seh是异常模型指结构化异常处理是 64 位下唯一正确的选择。老教程里常见的sjlj是给 32 位准备的在 64 位下用 sjlj 会带来性能损失而且和某些库的异常展开不兼容。dwarf更是 32 位专属出现在 64 位包名里基本都是错的。这三个参数在包名里是连写的看的时候别漏参数位本包取值备选选错的后果架构x86-64i686与目标平台不符无法链接 64 位库线程模型posixwin32std::thread 编译失败或运行异常异常模型sehsjlj / dwarf异常展开失效、性能下降、链接报错运行库ucrtmsvcrt与新版 Windows SDK 冲突CRT 符号重复定义2.3 运行库 ucrt 与包版本 v11和系统 DLL 的对应关系ucrt指 Universal C Runtime是 Windows 10 之后系统自带的 C 运行库Win7 需要单独装更新。用 ucrt 编译出来的程序运行时依赖ucrtbase.dll在 Win10/11 上是系统组件分发时不用额外带。而msvcrt是更老的 VC 6.0 时代那套功能残缺和现代 C 标准库配合容易出问题。现在新包基本都以 ucrt 为主除非你要兼容非常老的系统否则不要选 msvcrt。包名末尾的rt-v11是运行时包的版本标记rt表示 runtimev11是这一系列运行时构建的编号。它跟 GCC 13.1.0 是配套的说明这个离线包里的运行时组件是和第 11 代工具链一起构建出来的。这一点在实际使用中的意义是不要把这个包里的 DLL 和别的版本的 MinGW 混用混用会出现「编译期头文件是新的、运行期 DLL 是旧的」这种最难查的黑匣子问题。3. 离线包落地解压路径、环境变量与配置文件离线安装包的核心优势就是不需要包管理器、不需要联网、不需要管理员权限放用户目录即可。但「解压」这两个字背后有几个必须做对的细节做错了就会出现命令找不到、路径带空格、多版本互相覆盖。3.1 解压位置与目录结构确认先建一个固定的工具链根目录我习惯用D:\dev\mingw64不要放在C:\Program Files下面那个路径带空格某些老旧的 Makefile 和脚本处理不了也不要放在桌面或下载目录路径里有中文和空格的概率太高。解压后检查目录结构应该能看到这些关键子目录# 解压后进入根目录确认关键文件存在 ls bin/gcc.exe bin/g.exe bin/mingw32-make.exe ls x86_64-w64-mingw32/lib/libstdc.a ls include/c/13.1.0/vectorbin下是驱动程序和工具x86_64-w64-mingw32是目标三元组目录里面放库和头文件include/c/13.1.0是标准库头文件路径。这三处任何一处缺失说明包下载不完整重新解压一遍别硬撑着往下走。有些打包方式会多套一层同名目录解压完先看清层级保证bin直接位于你设定的根目录下。3.2 PATH 配置优先级比路径本身更重要环境变量配置这一步是血泪经验高发区。正确做法是把D:\dev\mingw64\bin加到用户 PATH 的最前面不是追加到末尾。追加到末尾的话系统里原有的其他 gcc、conda 自带的编译器、某些 IDE 捆绑的工具链会抢先命中你就得到一个「明明装了新版却报旧版本号」的诡异现场。图形界面操作路径是系统属性 → 环境变量 → 用户变量里的 Path → 编辑 → 新建一行填入D:\dev\mingw64\bin→ 用右侧「上移」按钮把它顶到第一位。命令行方式当前用户无需管理员# 将 MinGW bin 目录置于用户 PATH 首位 $mingwBin D:\dev\mingw64\bin $oldPath [Environment]::GetEnvironmentVariable(Path, User) if ($oldPath -notlike *$mingwBin*) { [Environment]::SetEnvironmentVariable(Path, $mingwBin;$oldPath, User) }这段脚本先读当前用户的 Path判断目标路径是否已存在避免重复添加把 PATH 撑得越来越长PATH 过长会导致部分程序启动失败这是个隐蔽的坑。写入的是用户级变量不需要管理员权限也不影响系统其他账号。改完后必须新开一个终端窗口旧窗口的环境变量是启动时快照的不会自动刷新——这一条每年都能坑到一批人。3.3 验证编译器身份别让版本号骗了你配置完第一件事不是急着编译项目而是确认当前命中的到底是哪个编译器gcc -v g -v where gccgcc -v的输出里重点看三行Target: x86_64-w64-mingw32、Thread model: posix、gcc version 13.1.0。这三项和包名对得上才说明你用的是这个包。where gcc用来确认路径只有一条如果输出了多行回到 3.2 节清理 PATH。如果gcc -v报「无法将 gcc 项识别为 cmdlet」说明 PATH 没生效先检查路径拼写、是否新开了窗口如果报的是版本号不对那就是优先级问题用where gcc定位是谁在抢。4. 配置与编译链路让 gcc、g、make 真正可用版本确认无误后接下来要把这套工具链接进实际的项目构建流程。很多人卡在这一步不是因为工具链坏了而是因为 CMake、Makefile、IDE 里还残留着旧路径或者编译参数没跟着运行库走。4.1 编译参数与运行库一致性用 ucrt 工具链时编译和链接要保证运行库口径一致。写个最小用例先跑通# test_ucrt.cpp同时验证线程库与文件系统 #include iostream #include thread #include filesystem int main() { std::cout thread id: std::this_thread::get_id() \n; std::cout cwd: std::filesystem::current_path() \n; return 0; }编译命令g -stdc20 -O2 test_ucrt.cpp -o test_ucrt.exe -pthread-stdc20打开 C20 标准13.1.0 对这个标准的支持已经比较完整-O2是常规优化级别调试期可以换成-g -O0-pthread在 posix 线程模型下用于开启线程支持虽然 MinGW 上不加有时也能过但涉及std::thread时加上更稳妥。运行test_ucrt.exe能同时打印线程 ID 和当前目录说明线程库、文件系统库、C 运行库三者都是通的。如果这里报filesystem相关链接错误基本可以判定用的是老版本 GCC 或者 msvcrt 口径的包如果报线程相关的未定义符号那就是线程模型选成了 win32。4.2 CMake 与 Makefile 中的工具链指定命令行能编不代表项目能编CMake 项目最容易在工具链探测上翻车。稳妥的做法是显式指定编译器别让它自己猜cmake -S . -B build -G MinGW Makefiles ^ -DCMAKE_C_COMPILERD:/dev/mingw64/bin/gcc.exe ^ -DCMAKE_CXX_COMPILERD:/dev/mingw64/bin/g.exe ^ -DCMAKE_BUILD_TYPERelease cmake --build build -j 8-G MinGW Makefiles明确生成器避免 CMake 抓成 Visual Studio 的生成器两个CMAKE_*_COMPILER用绝对路径写死防止它从注册表或 PATH 里捡到别的编译器CMAKE_BUILD_TYPERelease让默认优化级别生效--build build -j 8并行编译核数按机器调整。路径里用正斜杠反斜杠在 CMake 参数里容易被当转义符。如果是手写 Makefile注意make命令的实际名字是mingw32-make.exe很多教程直接写make而 Windows 上并没有这个可执行文件。可以在bin目录下复制一份改名为make.exe或者直接用全名。提示如果 CMake 报CMAKE_C_COMPILER not found先单独在终端里执行一遍gcc -v确认命令行可用再回来跑 CMake九成是 PATH 或者路径拼写问题。4.3 在 IDE 里绑定这套工具链用 VS Code 的话在.vscode/c_cpp_properties.json里把编译器路径和标准库路径都写死别依赖自动探测{ configurations: [ { name: MinGW-13.1.0, compilerPath: D:/dev/mingw64/bin/g.exe, intelliSenseMode: windows-gcc-x64, cStandard: c17, cppStandard: c20 } ], version: 4 }compilerPath指向具体可执行文件intelliSenseMode选 gcc 系列标准版本与编译命令保持一致。这样头文件补全和跳转才会走这套工具链的include目录否则编辑器和编译器各看各的头文件会出现「编辑器不报错、编译报错」的割裂感。其他 IDE 思路一致找到编译器路径、标准库路径、调试器路径三项全部指向同一个根目录。5. 避坑与排查五条装 MinGW 时被反复踩的坑这一节全部来自实际装环境时遇到的现场按「现象 → 原因 → 解决」记遇到对应症状直接对号入座。5.1 编译通过但运行报缺 DLL现象g编译成功双击 exe 或者换台机器运行弹窗提示找不到libstdc-6.dll或libgcc_s_seh-1.dll。原因动态链接的标准库 DLL 位于D:\dev\mingw64\bin下本机靠 PATH 能找到所以能跑换环境后 PATH 里没有这个目录就找不到。另外如果系统里存在多个版本的libstdc-6.dll程序可能加载到旧的那份直接崩溃。解决分发时用-static参数静态链接标准库命令是g -static -static-libgcc -static-libstdc main.cpp -o app.exe。或者把bin下需要的 DLL 拷到 exe 同目录。两种方式各有取舍静态链接体积大但省事动态拷贝体积小但容易漏文件。5.2 版本号显示正确但标准库头文件缺失现象gcc -v显示 13.1.0可编译#include format或ranges时报「No such file or directory」。原因PATH 命中的是 13.1.0 的bin但实际调用的include目录不是这套的常见于系统里同时装了两套 MinGW 和一个 MSYS2头文件路径被别的工具链抢先。解决用g -v -E -x c -打印当前生效的头文件搜索路径看第一顺位的include/c/13.1.0是不是指向你的解压目录。不是的话回到 3.2 节修 PATH 优先级同时检查有没有残留的CPATH、C_INCLUDE_PATH环境变量这两个变量会额外叠加搜索路径是隐藏的干扰源。5.3 命令行能编译IDE 里一直报红现象终端里g一切正常VS Code 或某 IDE 的编辑器里满屏波浪线说找不到iostream。原因编辑器的 IntelliSense 走的是另一套配置和终端 PATH 无关。它可能还记着安装前的编译器或者自动探测失败了。解决按 4.3 节显式写compilerPath写完执行一次「重置 IntelliSense 数据库」命令。如果还不行检查工作区里有没有旧的.vscode配置残留删掉重新生成比逐个参数对更快。5.4 make 命令不存在或报错现象跟着教程敲make提示「无法将 make 项识别为 cmdlet」。原因MinGW-w64 自带的构建工具叫mingw32-make.exe不叫make.exe另外如果你装了 Git for Windows它自带的make也可能被优先命中行为和 MinGW 不完全一致。解决统一用mingw32-make或者在bin目录复制一份改名为make.exe。执行where make确认命中的是哪一个避免两个 make 混用导致规则解析差异。5.5 中文路径与空格导致的诡异链接错误现象编译单个文件没问题链接时报cannot find -lxxx或file not found把项目挪个位置就好了。原因路径里有中文、空格或者特殊字符MinGW 的部分工具对这类路径处理不完善尤其在带-I、-L、-l参数时更容易暴露。解决工程目录和工具链目录都放在纯英文、无空格路径下比如D:\dev\mingw64和D:\work\demo。这条看似啰嗦但它能消掉一整类无法从报错信息看出根因的问题。6. 装完怎么验证用一条命令确认这套工具链真的能用验证不是看到版本号就完事版本号只证明bin里的驱动程序存在不证明标准库、头文件、异常模型、运行库都对。我一般会跑一个「四合一」的探针程序覆盖 C20 标准库、线程、文件系统、异常展开四条链路一次跑通才算装好。# probe.cpp四合一验证任一环节缺失都会在编译或运行期暴露 g -v -E -x c - nul # 先打印头文件搜索路径 # 再编译下面这段#include iostream #include thread #include filesystem #include stdexcept int main() { // 1) 标准库版本与编译器版本 std::cout __VERSION__ \n; // 2) 线程模型能正常创建线程说明 posix 生效 std::thread t([]{ std::cout thread ok\n; }); t.join(); // 3) 文件系统库 std::cout std::filesystem::temp_directory_path() \n; // 4) 异常展开seh 模型下 try/catch 正常工作 try { throw std::runtime_error(seh ok); } catch (const std::exception e) { std::cout e.what() \n; } return 0; }编译g -stdc20 -O2 probe.cpp -o probe.exe -pthread。判定标准很明确输出__VERSION__里含13.1.0打印thread ok线程模型对打印一个临时目录路径文件系统库对打印seh ok异常展开对。四项全过说明这套x86-64-13.1.0-release-posix-seh-ucrt-rt-v11-r是完整可用的接下来再拿真实项目跑一遍cmake就足够放心了。还有两件小事值得养成习惯。一是每装完一套工具链把gcc -v的完整输出存一份到笔记里将来项目出问题可以直接比对环境差异这比凭记忆回忆「当时装的是啥版本」靠谱得多。二是发布程序前一律用-static编一次验证静态链接能跑通基本就排除了 DLL 路径问题这是后悔药里最便宜的一颗。从那以后我每次接手新机器第一件事不是装 IDE而是先把这个探针程序跑一遍四项全绿才开始 clone 项目。多花五分钟省掉的是半天查不到根因的调试。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
