Windows下MinGW-w64免安装版配置与GCC编译实战

简介一份已在Windows 64位环境下亲测可用的MingW64编译器工具集面向需要在Windows平台编写C、C或Fortran程序的开发者可直接解压启用免去官方安装流程的配置困扰也适合作为便携式GCC环境随用随取。压缩包共3125个文件以头文件h/hpp、静态库a/lib、编译器可执行文件exe及动态库dll为主整体大小仅48.14MB是一套精简但完整的GNU工具链包内目录结构清晰便于按需取用组件。该版本在CSDN已有10360人浏览学习社区认可度较高尤其适合新手开发者快速搭建Windows下的编译环境进阶用户也可将其嵌入脚本或CI流程使用整体兼容性与稳定性已得到较多用户验证使用门槛较低。包内除gcc、g等编译器本体外还包含mingw32-make、ld、as、gfortran等辅助工具以及丰富的标准库头文件能满足日常C/C/Fortran项目的编译、链接与调试需求无需依赖Visual Studio等商业IDE即可在命令行中完成从源码到可执行程序的完整构建。1. 为什么我最终扔掉安装版改用解压即用的 mingw64做 Windows 下的 C/C 开发绕不开 MinGW-w64 这套工具链。以前图省事都是从某个安装器一路 Next装完发现路径里带空格、系统 PATH 被塞了一堆东西换机器又要重新点一遍安装向导。后来换成 mingw64 的免安装压缩包版本直接解压、手动配一次环境变量反而更可控也更容易复现给同事。这篇文章就把我实际验证过可用、能直接解压使用的版本选择和解压后的配置步骤讲清楚。需要说明的是MinGW-w64 官方发布渠道其实长期没有统一的“绿色版”打包社区里流传的免安装包质量参差不齐。我踩过不少坑最后固定下来一套版本组合和目录规范之后在好几台机器上都是同一个步骤搞定。如果你也在找 mingw64 下载和安装教程或者正被各种安装器折腾得头疼这篇笔记能让你少走两小时弯路。2. 解压版 mingw64 的选型逻辑先搞清楚你拿它干什么2.1 为什么“直接解压无需安装”在 Windows 上更靠谱通常我们装 GCC 工具链安装器会往注册表写内容把 DLL 复制到 System32还会自动改全局 PATH。这套流程对普通用户友好但对开发者并不理想你同时需要多个 GCC 版本比如 8.1.0 和 13.2.0做交叉验证时安装器之间会互相覆盖卸载不干净残留的 PATH 项可能把命令行工具指向一个不存在的路径。解压版把整个工具链放在一个目录里比如C:\mingw64里面是bin、lib、include等标准布局。切换版本就是改一下当前会话的 PATH或者用一个小脚本切换。这相当于把工具链变成了软件包管理器里的“便携应用”不污染系统。我一般还会把这个目录放进 Git 仓库的tools文件夹里新同事克隆下来就能编译不用再跑安装向导。另一个实际理由是很多 CI 环境或者离线内网机器不允许执行安装器但允许拷贝压缩包。解压版在这种场景下是唯一可行的办法。之前我在一台没有外网权限的测试机上配编译环境就是靠 U 盘拷贝一个 prebuilt 的压缩包解压后直接编译通过。2.2 版本号怎么挑不要盲目下载“最新版”mingw64 的代码仓库本身是 MinGW-w64 项目实际发布的是 GCC、binutils、gcc-libs 等组件的组合。很多免安装压缩包其实是第三方从 MSYS2 里抽出来或者用 w64devkit 这类项目打的包。社区里流传较广的版本有这么几类Sourceforge 上 mingw-w64 官方发布页的压缩包例如x86_64-8.1.0-release-posix-seh-rt_v6-rev0.7z。这是老牌版本稳定但因为 GCC 8 年代较早对 C20/23 支持不全。w64devkit 的发布包比如w64devkit-x64-1.17.0.zip自带 GCC、make、gdb体积小解压即用适合做练习题或小项目。MSYS2 的mingw-w64-ucrt-x86_64-toolchain安装后将整个mingw64目录拷出来当便携版用。这种方式能取得较新的 GCC比如 13.x但依赖的 DLL 也比较多。我最终固定使用的是w64devkit-x64 的免安装 zip 包。原因是它的 bin 目录里同时带了gcc.exe、g.exe、gdb.exe、mingw32-make.exe和ld.exe压缩包不到 300MB解压完直接放到任意路径就能用。如果你需要编译 FFmpeg 4.4 这种大型 C 项目我建议用 MSYS2 的便携目录而不是 w64devkit因为 FFmpeg 的 configure 脚本会检测make、yasm、pkg-config等工具w64devkit 虽然带了 make但缺少 yasm还得另外准备。提示选择解压版本时重点看构建时依赖的运行时。MSYS2 的 ucrt 或 msvcrt 版本会影响生成 exe 在目标机器上是否需要 UCRT 运行库。Windows 10 和 11 自带 UCRT但老系统可能缺。2.3 解压后目录结构的最小自检拿到压缩包不要急着解压即用先检查几个关键文件。常见的打包方式有两种压缩包根目录直接是bin/gcc.exe或者根目录是mingw64/bin/gcc.exe。第一种解压到C:\后你得到C:\bin\gcc.exe第二种解压到C:\后得到C:\mingw64\bin\gcc.exe。我习惯统一整理成D:\dev\mingw64作为最终根目录里面必须能看到bin、lib、include、libexec这四个子目录。自检命令在 PowerShell 里执行# 进入你解压后的根目录例如 D:\dev\mingw64 cd D:\dev\mingw64 # 列出 bin 目录下关键可执行文件 ls bin\gcc.exe, bin\g.exe, bin\gdb.exe, bin\mingw32-make.exe # 查看 gcc 版本 .\bin\gcc.exe --version如果版本输出正常说明这个压缩包的核心文件没有缺失。如果提示缺少libgcc_s_seh-1.dll或libstdc-6.dll那说明解压目录里没有把这些运行时 DLL 放在bin下或者系统 PATH 找不到它们。此时不要去网上找单独 DLL 塞进 System32正确做法是回到原始包确认解压时没有漏文件。之前我遇到一次七牛云下载的压缩包解压后文件数少了一半就是因为下载过程中 zip 被截断重新下载才解决。3. 用免安装 mingw64 在本地跑通第一个 C 程序3.1 下载与解压的操作步骤如果你决定跟进 w64devkit先去它的发布页找后缀为.zip的包比如w64devkit-x64-1.17.0.zip。下载后放在一个不包含中文和空格的路径下例如D:\downloads。然后用 PowerShell 解压不建议用 Windows 自带的“全部提取”因为自带解压对长路径和符号链接处理不好。# 创建目标目录 New-Item -ItemType Directory -Path D:\dev -Force # 将下载好的 zip 解压到 D:\dev Expand-Archive -Path D:\downloads\w64devkit-x64-1.17.0.zip -DestinationPath D:\dev -Force # 查看解压出来的顶层目录名 Get-ChildItem D:\dev解压完成后你会看到D:\dev\w64devkit或D:\dev\w64devkit-x64-1.17.0这样的目录。为了统一重命名一下# 如果目录名是 w64devkit就用这个如果是别的先改 Rename-Item D:\dev\w64devkit D:\dev\mingw64逻辑说明Expand-Archive会把 zip 内所有内容解压到DestinationPath下如果压缩包根目录带一个文件夹那解压结果就在D:\dev\对应文件夹。重命名成mingw64是为了之后配置环境变量时路径短且好记。注意Rename-Item的路径要和实际解压出来的目录名保持一致建议先Get-ChildItem看看再动手。参数说明-Force在Expand-Archive里表示如果目标目录里有同名文件则覆盖但通常DestinationPath不存在时这个参数会静默创建目录。如果你遇到“目标目录已存在且非空”的报错说明之前解压过建议先删除目录再解压避免残留文件混淆。3.2 配置环境变量临时生效与会话生效环境变量配置有两个层级当前终端临时生效适合一次性的编译任务永久写入用户 PATH适合日常开发。我建议先试临时确认没问题再写永久避免配错了影响全局。# 临时设置只对当前 PowerShell 窗口有效 $env:Path D:\dev\mingw64\bin; $env:Path # 验证 gcc 可用 gcc --version如果命令输出类似gcc (GCC) 13.2.0这样的信息说明工具链已经就绪。接下来写一个最小 C 程序试试。// hello.c #include stdio.h int main(void) { printf(mingw64 portable works\n); return 0; }用 gcc 编译并运行gcc -Wall -Wextra hello.c -o hello.exe ./hello.exe参数说明-Wall和-Wextra开启常用警告保证代码里没有潜在隐患-o hello.exe指定输出文件名。如果编译后运行提示找不到libgcc_s_seh-1.dll说明你的 PATH 没有包含 mingw64 的 bin 目录或者这个 DLL 不在 bin 里。正常解压的包bin 目录下会有这个文件因为 gcc 生成的 exe 默认动态链接异常处理库。提示临时环境变量在 PowerShell 里只对当前会话有效。你关掉终端再开需要重新设置。但这反而是一个安全验证方式如果临时设置能编译但重新开终端后不行说明问题就在永久环境变量没配好。3.3 把 mingw64 写进用户 PATH 的两种方法确认临时方案没问题后再写永久路径。最稳妥的是通过系统设置界面操作但命令行方式更容易复现。以下是在 PowerShell 里写入用户级 PATH 的命令注意它不会覆盖已有条目而是追加到末尾。# 读取当前用户 PATH 到一个变量 $oldPath [Environment]::GetEnvironmentVariable(Path, User) # 如果还没包含 mingw64就追加 if ($oldPath -notlike *D:\dev\mingw64\bin*) { [Environment]::SetEnvironmentVariable(Path, $oldPath ;D:\dev\mingw64\bin, User) }执行完新开的终端才会生效。当前终端里如果要立即用可以刷新一下# 用当前进程的环境变量重新加载 $env:Path [Environment]::GetEnvironmentVariable(Path, Machine) ; [Environment]::GetEnvironmentVariable(Path, User)逻辑说明上面的刷新语句把系统级和用户级 PATH 拼接后赋给当前进程这样就不用重启终端。但注意如果之前手动设置过临时 PATH这个操作会覆盖它所以建议在干净终端里执行。参数说明[Environment]::SetEnvironmentVariable的第三个参数User表示作用于当前用户不会影响其他用户。如果你希望所有系统用户都能用可以改成Machine但普通用户对C:\或D:\下的目录没有写权限运行时可能会遇到权限问题所以我不推荐全局设置。4. 用免安装 mingw64 编译 FFmpeg 4.4完整命令与参数要点4.1 为什么 FFmpeg 4.4 是验证工具链的好目标很多人拿到 mingw64 后第一件事就是编译 FFmpeg因为 FFmpeg 的 configure 脚本会调用编译器、汇编器、归档器还能顺带检测你的工具链是否接近 Linux 行为。我选择 FFmpeg 4.4 作为验证项目是因为它相比最新的 6.x 或 7.x对编译器版本要求没那么激进GCC 8 以上都能过而且网上能搜到的“mingw64 编译 ffmpeg4.4”教程很多碰到问题容易对照。不过有一件事必须提前说明用 w64devkit 直接编译 FFmpeg 4.4 比较痛苦因为 FFmpeg 需要yasm或nasm而 w64devkit 默认不带。所以这一步我用的是 MSYS2 的便携 mingw64 目录或者你可以在 w64devkit 里额外放一个yasm.exe。常见的做法是下载yasm-1.3.0-win64.exe改成yasm.exe放进bin目录但注意版本要匹配太新的 yasm 反而可能不支持旧的 x86 汇编语法。4.2 用 MSYS2 的 mingw64 目录当便携工具链MSYS2 安装器虽然是一个安装程序但它装完后的C:\msys64\mingw64目录本身就是完整的工具链目录你可以把这个目录整个复制到别的盘当便携版。我不推荐直接动安装器本身而是先在一台机器上完成 MSYS2 的安装然后运行以下命令更新工具链# 在 MSYS2 终端里执行 pacman -Syu --noconfirm pacman -S --needed base-devel mingw-w64-x86_64-toolchain mingw-w64-x86_64-yasm mingw-w64-x86_64-pkg-config更新完成后C:\msys64\mingw64\bin里就有了gcc.exe、yasm.exe、pkg-config.exe等。然后把这个目录复制出来# 在 PowerShell 中执行注意路径 Copy-Item -Recurse -Force C:\msys64\mingw64 D:\dev\msys64-mingw64复制过程中可能会遇到个别符号链接或硬链接损坏的问题但通常不影响编译。复制完成后把D:\dev\msys64-mingw64\bin放在 PATH 的靠前位置确保gcc和yasm都来自这个目录而不是系统自带的其他版本。4.3 configure 与 make 的完整参数以及我踩过的坑下载 FFmpeg 4.4 源码进入目录后按以下步骤执行。注意一定要在 MinGW 环境里执行不能直接使用 Windows 自带的 PowerShell 跑./configure因为脚本依赖sh和 POSIX 命令。你可以用 MSYS2 的 bash 终端或者把C:\msys64\usr\bin\bash.exe单独调起来。# 假设我们已进入 ffmpeg-4.4 源码根目录 export PATH/d/dev/msys64-mingw64/bin:$PATH ./configure \ --toolchainmingw32 \ --archx86_64 \ --target-osmingw32 \ --enable-cross-compile \ --cross-prefixx86_64-w64-mingw32- \ --disable-doc \ --disable-debug \ --enable-gpl \ --enable-version3 \ --disable-d3d11va \ --disable-dxva2 \ --disable-schannel make -j8参数说明--cross-prefix指定工具链前缀如果你的gcc.exe名字就叫x86_64-w64-mingw32-gcc.exe那前缀就是x86_64-w64-mingw32-。MSYS2 的工具链通常同时提供无前缀和多前缀的版本如果只有一个gcc.exe你可以去掉--cross-prefix和--cross-compile直接让 configure 检测本机编译器。--disable-d3d11va和--disable-dxva2是关掉 Windows 硬件加速解码我这样做的原因是这两个模块在纯 mingw 环境下经常遇到 dxva 头文件版本冲突如果不关编译时会在libavcodec/d3d11va.h和dxva2.h附近报一堆错。make -j8的-j参数表示并行编译任务数一般设为本机 CPU 核心数或稍大。但 FFmpeg 的某些源文件有前后依赖并行数过大偶尔会出现“header 文件找不到”的假报错。遇到这种情况先执行make -j1复现一次如果通过就说明不是源码问题而是并行编译的资源竞争把数字缩到核心数一半即可。4.4 编译结果验证生成 ffmpeg.exe 与 ffprobe.exe如果一切顺利编译结束后在源码目录的ffmpeg.exe、ffprobe.exe会生成出来。验证它们是否正常工作不能只看文件存在还要跑一次实际转码测试# 生成一个 3 秒的测试视频 ./ffmpeg.exe -f lavfi -i testsrcduration3:size640x480:rate30 -f lavfi -i sinefrequency440:duration3 -c:v libx264 -c:a aac -movflags faststart test.mp4 -y执行后如果没有报错并且生成的文件大小超过 100KB基本说明你这套 mingw64 工具链已经具备编译真实项目的能力。比这更严格的做法是用ffmpeg.exe -decoders查看解码器列表确认没有因为禁用d3d11va导致解码器数量异常其实那个开关只影响硬件加速软件解码器不受影响。注意如果你在 configure 后修改了工具链路径或者把 mingw64 目录移了位置必须删掉config.*和编译产物重新 configure。FFmpeg 的配置会记录绝对路径移动后直接 make 会报“No such file or directory”。5. 解压版 mingw64 的常见故障排查现象、原因、解决5.1 现象运行 gcc 报 “不是内部或外部命令”这是最典型的 PATH 配置问题。表现为你在任意目录输入gcc系统提示找不到命令但直接进到D:\dev\mingw64\bin目录下执行gcc.exe却正常。原因当前终端的 PATH 环境变量里没有包含D:\dev\mingw64\bin。可能是你只设置了临时 PATH重开终端后失效或者你设置了用户 PATH但当前终端没刷新。解决先用绝对路径确认工具本身没问题D:\dev\mingw64\bin\gcc.exe --version如果这个能跑再按上面 3.3 的刷新命令重载 PATH。刷新后检查$env:Path -split ; | Select-String -Pattern mingw64如果没有输出任何匹配说明 PATH 写入没成功或写错了路径。注意检查路径里的分隔符用户 PATH 的追加要用分号不要用空格。5.2 现象编译出的 exe 运行时报缺少 DLL有时候 gcc 编译正常exe 也生成了但双击运行或者从控制台运行时报libgcc_s_seh-1.dll not found或libstdc-6.dll not found。原因这些 DLL 存在于 mingw64 的bin目录但系统运行时找不到。常见原因有两个PATH 没包含 mingw64 的 bin或者你在编译时用了-static-libgcc -static-libstdc也没有解决问题因为还有libwinpthread-1.dll等额外依赖。解决先检查 DLL 是否真的在 bin 里Test-Path D:\dev\mingw64\bin\libstdc-6.dll如果不存在说明这个解压包不完整重新下载或者换一个打包来源。如果存在确认 exe 和这些 DLL 在同一个目录下再运行。对于需要分发给别的机器的场景我一般直接用gcc -o hello.exe hello.c -static -static-libgcc -static-libstdc这样生成的 exe 不再依赖任何动态运行时文件会大几倍但放到任何 Windows 机器上都能跑。代价是哈编译出来的可执行文件体积从 100KB 变成 1MB 左右这是常态。5.3 现象make 命令不存在或版本不对很多项目用 Makefile 构建你在解压版 mingw64 的 bin 目录里找到了mingw32-make.exe但项目执行make时报找不到命令。原因mingw32-make 和 GNU make 在 Windows 上名字不同。MSYS2 的 mingw64 工具链提供的是mingw32-make.exe而不是make.exe。有些项目写死了 Makefile 里的make命令需要你额外创建别名或符号链接。解决在 bin 目录里复制一份Copy-Item D:\dev\mingw64\bin\mingw32-make.exe D:\dev\mingw64\bin\make.exe然后验证make --version如果项目里还用了pwd、rm、cp这些 Unix 命令单纯的 mingw64 工具链也满足不了建议直接换用 MSYS2 的环境那里有完整的 POSIX 工具集。5.4 现象GCC 版本够新但编译 C17 代码报std::string_view找不到这不是编译器版本太老而是你的头文件搜索路径没有包含 GCC 自带的 C 标准库头文件。比如 std::string_view 在 GCC 7 以上就支持但如果 include 路径被某个第三方库污染就会出错。原因解压版目录如果被移动lib\gcc\x86_64-w64-mingw32\version\include\c的相对路径没有变化但某些项目里通过-I手动指定了其他 include 目录覆盖了默认搜索路径的第一项。解决先用 gcc 的预处理参数检查实际头文件路径gcc -v -E -x c - /dev/null 21 | Select-String -Pattern 搜索|Search观察输出里 include 路径是否包含D:\dev\mingw64\include\c\13.2.0这类目录。如果没有检查环境变量CPATH或C_INCLUDE_PATH是否被设置了。我之前就是因为在系统变量里加了CPATHC:\other\include把它删掉后问题就消失了。6. 把解压版 mingw64 用成“后悔药”目录克隆与版本隔离6.1 在同一台机器上并排多套工具链既然解压版不污染系统路径我倾向于在D:\gcc-toolchains下同时保留几个版本比如一个 GCC 8 用于老项目一个 GCC 13 用于新项目。每个版本用自己的目录切换时只改当前终端的 PATH 前缀互不干扰。目录结构这样组织D:\gcc-toolchains\ ├── mingw64-gcc8\ │ └── bin\gcc.exe ├── mingw64-gcc13\ │ └── bin\gcc.exe └── switch.ps1对应的切换脚本PowerShell# switch.ps1 用法.\switch.ps1 gcc13 param([string]$ver) $base D:\gcc-toolchains\mingw64-$ver\bin if (!(Test-Path $base)) { Write-Host 版本不存在: $ver exit 1 } $env:Path $base ; $env:Path之后在任意终端执行. .\switch.ps1 gcc13当前会话的 gcc 就变成对应版本。注意此处我用的是“点”加空格的方式调用脚本这样环境变量的修改会保留在当前进程中否则脚本结束后变量会被丢弃。6.2 用gcc -v验证“当前用的是哪个版本”多套工具链最容易出现“明明切了版本但编译时还是旧版”的情况。我常用的排查技巧是在项目根目录执行gcc -v 21 | Select-String -Pattern COLLECT_GCC输出里的COLLECT_GCC/path/to/gcc.exe就是你当前实际使用的编译器路径。如果这个路径不是你预期的那套检查 PATH 顺序更靠前的 bin 目录会优先命中。PowerShell 里可以用$env:Path -split ; | Where-Object {$_ -like *gcc*}看看里面有几个 mingw64 路径按照从上往下的顺序第一个存在的 gcc.exe 会被选中。6.3 一个让我少折腾两次的编译技巧给 CMake 与 FFmpeg 单独传编译器路径很多构建系统并不完全相信 PATH 环境变量比如 CMake 一旦配置好之后会记录编译器绝对路径。如果你移动了 mingw64 目录CMake 缓存里的路径失效就会报“CMAKE_C_COMPILER-NOTFOUND”。此时不要重新装 CMake直接删除项目的CMakeCache.txt再重新 configure。我一般会养成习惯在 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_MAKE_PROGRAMD:/dev/mingw64/bin/mingw32-make.exe这个习惯也救过我一次项目里其他人安装的 Visual Studio 自带了一个cl.exeCMake 默认检测到了 MSVC导致所有 GCC 专属编译选项被忽略。显式指定编译器后整个项目回归正轨。6.4 最后说句老实话明确定位自己是“便携工具链使用者”就不要试图把一个解压版优化成完全兼容 Unix 的完整环境。它能解决编译器的存在性问题但解决不了所有项目的基于 POSIX 的构建脚本。真正把免安装 mingw64 用顺手的核心是坚持同一目录、同一 PATH 顺序并且把版本信息写进项目的 README。遇到再奇怪的报错先执行gcc -v看当前到底是哪套编译器再翻 config 日志最后再骂变量。这套方法陪我从 GCC 8 一路用到 GCC 13没走过弯路希望帮到你。本文还有配套的精品资源点击获取