mingw64解压即用：Windows上配置GCC工具链并编译ffmpeg

简介mingw64是Windows平台下的64位GNU编译器集合本资源为亲测有效的免安装版本直接解压即可使用省去配置安装过程中的诸多麻烦非常适合需要快速搭建C/C开发环境的开发者。压缩包共3125个文件大小48.14MB涵盖C/C头文件.h、.hpp、静态库与目标文件.a、.lib、.o、编译器可执行程序.exe等另外包含gfortran等扩展编译工具构成一套完整的64位Windows原生开发工具链。目前已有10360人学习下载口碑验证了其稳定可靠。解压后只需设置环境变量就能立刻使用gcc、g等命令进行代码编译同时附带的头文件与静态库也能直接支撑项目构建对新手友好也能节省中高级开发者配置环境的时间。1. mingw64 解压即用这套工具链值得直接收进硬盘很多人在 Windows 上配 C/C 编译环境第一反应是装 Visual Studio几 GB 装完还要面对工程配置的复杂性。mingw64 是另一条路它是 GCC 工具链的 Windows 移植版把压缩包解压到任意目录、配好 PATH就能在命令行里编译出原生 Windows exe。我亲测的这个版本不需要安装程序、不写注册表、不污染系统删掉文件夹就是彻底卸载比 MSYS2 全套安装轻量得多。这份资源适合三类人需要快速搭一个 C/C 编译环境的初学者要在 Windows 上交叉编译 Linux 风格代码的开发者以及想用 ffmpeg 4.4 源码在 Windows 下自己编一套库的折腾型选手。下文我会把版本选型、环境配置、编译 ffmpeg 的完整流程和踩过的坑一次说清楚。2. 先把工具链搞明白mingw64 的版本差异与选型理由2.1 i686 与 x86_64、seh 与 sjlj这些后缀到底怎么选mingw64 的压缩包名字里通常带一串后缀比如x86_64-posix-seh、i686-win32-sjlj新手看到容易懵。这串后缀由三部分组成每一项都直接决定你编出来的程序能不能跑、跑多快、遇到异常会不会崩。架构部分看前面x86_64是 64 位i686是 32 位。现在新写的代码基本都应该选 64 位不仅是内存寻址范围更大而且 64 位下有些浮点运算和整数运算的速度也有优势。我见过有人为了兼容旧机器误选了 i686编出来的 exe 在 64 位 Windows 上也能跑但纯粹是没必要地损失了性能。中间部分说的是异常处理模型Windows 下主要是seh和sjlj。SEH结构化异常处理是 Windows 原生的机制性能好但它要求编译器生成特定的栈布局信息SJLJsetjmp/longjmp是跨平台的老方案牺牲性能换可移植性。mingw64 官方推荐的组合就是x86_64-posix-seh这个组合在性能、C 异常支持、线程模型上都最稳。最后一段posix意思是线程模型遵循 POSIX 标准比win32模型更完整地支持 C11 的std::thread——如果你要编译涉及多线程的现代 C 代码必须选posix否则会碰到莫名其妙的链接错误。组合架构异常模型线程模型适用场景x86_64-posix-seh64 位SEHPOSIX默认首选ffmpeg 等大型项目都用它x86_64-win32-sjlj64 位SJLJWin32老工程兼容不推荐新项目i686-posix-dwarf32 位DwarfPOSIX32 位编译dwarf 只能在 32 位下用i686-win32-sjlj32 位SJLJWin32复古项目别碰我用的就是x86_64-posix-seh这套组合出问题的概率最小。下载之后直接解压到C:\mingw64目录结构一目了然bin下是 gcc、g、make、gdb 这些可执行文件lib下是库文件include下是头文件。后面所有的环境配置都围绕这三个目录展开。2.2 解压即用的前提目录结构与 PATH 变量mingw64 解压以后不需要运行任何安装脚本但前提是你得让 Windows 能找到它。这里的关键就是 PATH 环境变量。Windows 在执行命令时会按 PATH 里列出的目录顺序逐个查找gcc.exe、g.exe找不到就报“不是内部或外部命令”。我习惯的做法是解压到固定位置而不是桌面。把压缩包解压到C:\mingw64然后确认C:\mingw64\bin\gcc.exe存在这一步看起来简单但解压中断或者路径带中文都会导致后续找不到命令。配置 PATH 有两种方式临时生效和永久生效。临时生效在命令行里执行set PATHC:\mingw64\bin;%PATH%这条命令在当前终端窗口里把 mingw64 的bin目录加到最前面缺点是关掉终端就失效。永久生效用setxsetx PATH C:\mingw64\bin;%PATH%注意setx有一个隐藏坑它会把 PATH 值截断到 1024 个字符如果你原来的 PATH 很长用setx直接把新的串覆盖进去可能会截掉后面的变量。我一般建议打开“系统属性 → 环境变量”在用户变量里找到 PATH点编辑把C:\mingw64\bin加进去这是最不容易出错的方式。2.3 验证工具链是否可用gcc、g、make 一条龙配好环境变量后开一个新的命令行窗口旧窗口不会刷新 PATH逐个验证gcc --version g --version make --version gdb --version如果输出里能看见版本号比如gcc.exe (MinGW-W64 x86_64-posix-seh) 8.1.0说明工具链基本可用。我建议重点看两处第一架构是不是x86_64第二线程模型是不是posix。这两项如果和你需要的不一致后面编大型项目时会出现诡异的错误。还有一个容易被忽略的验证项ld链接器版本。有些精简版压缩包里没带完整的 binutils 工具集编译小文件看不出来一到链接多个目标文件就失败。验证方法是直接跑一句带链接的命令看能否生成 exe。这一步别省很多抱怨“mingw64 编译报错”的人实际上是用了一个不完整的发行包。3. 把 mingw64 装进系统解压、配环境与编译实战3.1 解压到指定目录并确认文件完整性前面说过我推荐解压到C:\mingw64但如果你不想动 C 盘放D:\Tools\mingw64也完全可以。关键是整个工具链文件夹必须是完整的bin 目录下至少要能看到这些文件可执行文件作用gcc.exeC 编译器g.exeC 编译器mingw32-make.exemake 工具与 Unix make 存在细节差异gdb.exe调试器ar.exe静态库管理工具objdump.exe二进制文件分析工具windres.exeWindows 资源文件编译器用压缩软件解压时尽量选择“解压到当前文件夹”而不是双击进压缩包内操作有些压缩软件在中文路径下解压大文件会中断中断后目录看起来完整但个别 exe 其实是 0 字节。我吃过一次这种亏当时 configure 一直报错排查半天才发现是ld.exe损坏。验证完整性的最简单办法是看整个mingw64文件夹的大小通常应该在 1 GB 以上含全部库文件如果解压出来只有两三百 MB基本可以确定是缺文件了。3.2 配置 Windows 环境变量用户级 vs 系统级配置环境变量时有个容易忽视的层级问题。Windows 的环境变量分系统级和用户级系统级对这台机器上所有用户生效用户级只对当前账户生效。开发者自用的话配用户级就够因为不需要管理员权限。操作路径是右键“此电脑” → 属性 → 高级系统设置 → 环境变量。在“用户变量”里找到Path点击编辑新建一行填入C:\mingw64\bin。这里有一个关键细节一定不要把 mingw64 的 bin 目录加到系统变量的 Path 里除非你确定这台机器就是专用工作站。因为 mingw64 自带的find.exe、sort.exe等工具会和你系统里本来就有的工具重名加进系统级会让其他程序意外调用到 GNU 版本的工具引发一些疑难杂症。配置完成之后开一个新的 cmd 窗口一定不要复用之前打开的跑where gcc如果输出了C:\mingw64\bin\gcc.exe说明 PATH 已经生效。where命令比gcc --version更适合验证 PATH 顺序因为你能直接看到命令行找的是哪个目录的 gcc——万一系统里之前装过别的 GCCwhere gcc会列出所有匹配路径你立刻就能判断优先用的是哪个。3.3 第一个编译测试从 hello.c 到 hello.exe环境配好之后写一个最简单的 C 文件做全链路验证。新建hello.c#include stdio.h int main(void) { printf(mingw64 works, pid%d\n, getpid()); return 0; }然后用 mingw64 编译gcc -Wall -O2 -stdc11 hello.c -o hello.exe这个命令里的参数各有用途-Wall打开所有常见警告新手写代码时别关它-O2是优化级别编译测试程序时无所谓但编译 ffmpeg 这类大型项目时建议至少-O2-stdc11指定 C 语言标准-o hello.exe指定输出文件名。编译完成后直接执行hello.exe如果能看到输出且没有弹窗报缺 DLL说明这一套环境能正常干活。这一步还有一个值得盯的细节编译时如果警告里出现mingw32相关的头文件找不到比如stdio.h: No such file or directory说明你用的不是完整的 mingw64 包而是某个只带了编译器的精简版。遇到这种情况直接换一个完整版本别在自己机器上花时间补头文件。3.4 编译带依赖的代码链接 lib 与静态/动态库选择实际项目很少只有一个文件这里用一个带链接的示例演示。假设有一个mylib.c需要编成静态库再在main.c里调用gcc -c mylib.c -o mylib.o ar rcs libmylib.a mylib.o gcc main.c -L. -lmylib -o prog.exe第一条命令-c是只编译不链接生成目标文件mylib.o。第二条ar rcs libmylib.a mylib.o把目标文件归档成静态库rcs三个字母分别代表“替换同名成员”“创建库文件”“写入索引”。第三条命令的-L.告诉链接器在当前目录找库-lmylib表示链接libmylib.a注意-l后面不用写全名。链接器这块有个常见误区如果你同时有libmylib.a和libmylib.dll.a导入库默认优先选动态库而不是静态库。静态链接的 exe 拷到别的机器上直接能跑动态链接的 exe 依赖 DLL分发时需要连带带走。GCC 的默认行为更偏向动态如果你想强制静态链接加-static参数。这个选择在 ffmpeg 编译时也会碰到后面细说。4. 拿 mingw64 去编译 ffmpeg 4.4完整流程与参数说明4.1 为什么要选 ffmpeg 4.4 加 mingw64 这个组合ffmpeg 4.4 是 2021 年发布的版本到现在依然被很多项目用作基础版本原因在于它处于“新功能够用、稳定性已验证”的平衡点。mingw64 编译 ffmpeg 的好处是能拿到纯 Windows 原生的ffmpeg.exe和一堆 DLL不依赖 MSYS2 的运行时环境。很多人卡在这一步其实不是工具链不行而是 configure 参数没配对。mingw64 编译 ffmpeg 最常见的需求是获取 DLL 版本的库便于后续二次开发。这里的核心难点在于 ffmpeg 的 configure 脚本会检测编译器环境、头文件、汇编器任何一环不对都会在编译中途报错。我下面给的参数组合是我亲测可过的直接抄作业成功率很高。4.2 安装 msys2 与依赖pkg-config、nasm、yasmffmpeg 的 configure 脚本是 Unix 风格的在纯 Windows cmd 下也能跑但依赖pkg-config、nasm、yasm这几个工具。mingw64 解压包本身不带这些需要另想办法。最省事的方式是装一个 MSYS2用它来安装 ffmpeg 的编译依赖但编译本身用 mingw64 的工具链。这个听起来有点绕实际操作是这样MSYS2 装完后在它的终端里执行pacman -S nasm yasm pkg-config diffutils这几个工具的作用分别是nasm和yasm是汇编器ffmpeg 里的视频编码优化代码有一大部分是汇编写的configure 检测不到汇编器就会自动禁用这些优化编译出来的 ffmpeg 性能会差不少pkg-config用来检测依赖库的编译参数diffutils提供diff命令ffmpeg 的 configure 脚本会用到它来做配置验证。安装完之后MSYS2 的工具默认在C:\msys64\usr\bin和C:\msys64\usr\bin\nasm.exe这些路径。为了在 cmd 里直接调用我把 MSYS2 的几个 bin 目录也临时加进了 PATH 前缀但注意顺序C:\mingw64\bin必须放在最前面否则 fftmpeg 的 configure 会错误地使用 MSYS2 自带的 GCC 来编译产物就变成依赖 MSYS2 运行时环境的了。4.3 配置 configure 参数--enable-shared --disable-static 等进入 ffmpeg 4.4 的源码目录执行下面的配置命令。这是整个流程中最容易翻车的环节参数直接决定成败./configure --archx86_64 \ --target-osmingw64 \ --cross-prefixx86_64-w64-mingw32- \ --enable-shared \ --disable-static \ --enable-small \ --disable-doc \ --disable-debug \ --enable-gpl \ --enable-libx264 \ --extra-cflags-O2 -marchx86-64逐条说明这些参数的作用--archx86_64指定目标架构为 64 位。--target-osmingw64是关键的交叉编译标志告诉 configure 我们要的是 Windows 原生程序而不是 Linux 程序。--cross-prefixx86_64-w64-mingw32-指定编译器前缀这个字符串必须是你的 mingw64 工具链实际的名字如果你的 gcc.exe 不叫x86_64-w64-mingw32-gcc.exe这里就要改成x86_64-w64-mingw32-为前缀的路径或者直接去掉这一行让 configure 用默认的gcc。--enable-shared是这次编译的核心诉求输出 DLL 格式的 ffmpeg 库--disable-static关闭静态库输出避免两种格式混在一起增加链接时的不确定性。--enable-small让编译器优化体积编译时间也会缩短。--disable-doc跳过文档生成纯节省时间。--disable-debug移除调试符号生成的 exe 和 DLL 会小很多。最后一行--extra-cflags传入的-marchx86-64是让编译器按通用的 64 位指令集生成代码这样编出来的程序能在绝大多数 6 4 位 Windows 上运行。如果你确定只在自己机器上用可以考虑-marchnative获得更好的指令集优化但换机器就有崩的风险。这一步视你的使用场景决定我一般保守用x86-64。configure 结束后会输出一份摘要重点看这几行C compiler gcc、nasm/yasm是否为 enabled、pkg-config是否找到。如果摘要里出现nasm not found或者yasm not found后面编译必挂回头补装即可。4.4 make 与 make install编译时长与产物验证configure 成功后进入编译阶段make -j8-j8让 make 同时跑 8 个编译任务这个数不是越大越好建议按你 CPU 物理核心数来。如果你机器是 4 核用-j4如果是 8 核 16 线程可以-j16。开的编译任务太多会耗尽内存反而比串行更慢。ffmpeg 4.4 在-j8下大概需要 10 到 20 分钟期间终端会不停滚动编译日志看到gcc和nasm交替出现就说明在正常工作。编译完成之后不要直接跑 ffmpeg.exe先执行安装步骤make install默认会装到C:\msys64\usr\local或者 configure 时指定的前缀目录。安装完成后去bin目录看一眼应该能看到ffmpeg.exe、ffprobe.exe、ffplay.exe三个主程序还有一堆以avcodec-58.dll、avformat-58.dll命名的动态库。这时候执行ffmpeg -version输出里会出现ffmpeg version 4.4 ... configuration: --enable-shared ...的字样看到enable-shared就说明你编的是 DLL 版本。这一步值得认真做一遍因为很多人在配置参数里写了--enable-shared实际出来的却是静态版原因就在于 configure 时没有真正重新生成配置缓存用了默认配置。5. mingw64 避坑指南亲测中遇到的五个典型问题5.1 现象解压后 gcc 报“不是内部或外部命令”这个报错几乎是 mingw64 新手遇到的第一个坑。我当时解压完满怀信心地敲gcc --version结果 cmd 直接甩了一句不是内部或外部命令。排查到最后发现是两个原因叠加第一解压路径里有个空格压缩包放在D:\My Tools\mingw64里虽然 PATH 配的是完整的带空格路径但个别命令行工具在解析时没有正确加引号第二配完 PATH 后我没有开新终端旧终端的变量池里完全不知道这事。解决方法是把文件夹移动到无空格的路径比如D:\mingw64然后关掉所有命令行窗口重新打开。从那以后我下载任何压缩包工具第一步就是确认路径纯英文无空格。5.2 现象编译出来的 exe 在别的机器上跑不起来在开发机上编译运行都没问题拷到同事电脑上双击没反应或者弹窗提示缺libwinpthread-1.dll。原因是 mingw64 的 posix 线程模型会让程序依赖这个运行时 DLL而你编译时默认是动态链接。解决的办法有两个一是分发时把libwinpthread-1.dll连同 exe 一起给别人二是编译时加-static参数把所有运行时库打进 exe。静态链接的缺点是 exe 体积会变大几十到几百 KB但换来的是分发省心。我自己的习惯是工具类小项目一律-static用到 opencv 这种大库时才考虑动态链接。5.3 现象configure 卡在“checking for nasm”且结果一直为 noffmpeg 的 configure 脚本会精确地找nasm和yasm找不到就老老实实禁用汇编优化但不会中断。如果你没注意摘要里的 no编译出来的 ffmpeg 视频处理能力会明显下降。我当时遇到这个问题的原因是nasm 虽然装了但 configure 是在 cmd 里跑的cmd 的环境变量没刷新找不到C:\msys64\usr\bin\nasm.exe。解决方法是重新开一个终端或者手动把 nasm 所在目录加到 PATH 前部。另一个隐蔽原因是 NASM 版本过低ffmpeg 4.4 需要 nasm 2.13 以上我那次装的 2.11 版本直接被 configure 判定为不可用。5.4 现象编译过程中异常报错关于 stdint.h 的冲突mingw64 自带的stdint.h和 ffmpeg 源码里包含的stdint.h在类型定义上存在冲突报错信息里往往有redefinition of typedef int64_t之类的字样。这是 Windows 平台编译类 Unix 项目的经典问题不是你的代码写错了。解决方法是加一条编译参数--extra-cflags-D__STDC_CONSTANT_MACROS以及必要时加-D__STDC_LIMIT_MACROS。这么做的原理是让 ffmpeg 源码在包含头文件时使用系统头文件的类型定义避免双重定义。不必纠结原理细节遇见 typedef redefinition 就试着加这两个宏十有七八能解决。5.5 现象make 编译到一半卡死或者报“out of memory”ffmpeg 这种项目有几个特别吃内存的编译单元比如libavcodec下的某些大文件单个文件编译就可能消耗 2 GB 内存。如果你的-j参数开得太大同时有 8 个这样的编译任务在跑内存立马爆掉。我经历过的现象是系统突然卡顿然后终端里一堆Killed字样。解决方案是把-j8改成-j4甚至-j2增加 make 期间的内存压力会小很多。另外也可以在 configure 时加上--disable-debug这样编译器不需要生成调试信息内存占用会少一截。编译这种大项目宁可慢一点也别试图把 CPU 拉满。6. 把 mingw64 用得更顺手环境变量持久化与交叉编译小技巧6.1 写一个环境配置脚本一键切换多个工具链mingw64 解压即用的特性让它在多开发环境并存这件事上很有优势。我会在项目根目录放一个env.bat每次打开终端project\env.bat就切好环境echo off set PATHC:\mingw64\bin;%PATH% set CCgcc set CXXg echo MinGW64 environment ready.这个脚本做的事很简单把 mingw64 的bin目录塞到 PATH 最前面同时把默认编译器变量指向 gcc。如果你的电脑上还装了 MSYS2 或者 Strawberry Perl它们各自的工具也会往 PATH 里挤这个脚本能保证你这个终端窗口里优先使用 mingw64 的工具链避免被其他环境的同名工具干扰。6.2 用 mingw32-make 与 make 的差异避免“找不到命令”mingw64 包里的 make 程序默认叫mingw32-make.exe而很多项目的构建脚本写的是make。两者的区别是mingw32-make是 GNU make 在 Windows 上的编译版它不处理路径里的正斜杠与反斜杠差异、不识别 Unix 风格的软链接。如果你在 cmd 里敲make找不到命令可以测试一下mingw32-make --version是否正常。我一般会在env.bat里加一行set MAKEmingw32-make再用mingw32-make开头的命令跑构建脚本。另一种更顺手的做法是复制一份copy mingw32-make.exe make.exe但如果这个版本更新了你得记得重新复制。6.3 验证最终产物objdump 查看 DLL 依赖编译完成不是终点验证 exe 是否可分发才是收尾。我习惯用objdump查看目标程序的依赖objdump -p ffmpeg.exe | grep DLL Name输出会列出所有它依赖的 DLL比如libwinpthread-1.dll、libgcc_s_seh-1.dll、libstdc-6.dll。如果是静态链接的版本你会发现输出里只剩下系统 DLL比如KERNEL32.dll、MSVCRT.dll。这个验证技巧能帮你判断 exe 能不能直接拷给别人也帮你发现哪些 DLL 忘了分发。mingw64 自带的几个运行时 DLL 在C:\mingw64\bin里缺哪个就复制哪个或者干脆用-static消灭这些依赖。这些年我在 mingw64 上踩过的坑不算少但每次踩完都发现是自己对工具链的理解还不够细而不是工具本身不行。从那以后我每次下载新版本 mingw64拿到手第一件事永远是做一遍第 2.3 节里的三连验证第二件事就是直接编一个 ffmpeg 4.4跑通才算数。希望这个流程能帮你少走一点弯路也希望你拿到这个亲测版本后能更快地把时间和精力花在真正要写的代码上。本文还有配套的精品资源点击获取