1. 不是你不会装MinGW64是你没人告诉你该选哪个先说个明白话MinGW64这东西装不上、装完跑不起来、gcc报错十有八九不是你没本事而是这工具本身的分发包和版本实在太乱了。你搜“MinGW64 安装”能得到至少四种互相打架的教程有的让你去SourceForge下离线安装包有的让你去MSYS2里敲一条命令还有的直接丢给你一个绿色版压缩包。我估摸着这就是“不会安装MinGW64”这句话背后最真实的火气——不是不会是不知道该信谁。MinGW64的全称是MinGW-w64是原版MinGW的一个分支项目主要目的就是在Windows上原生编译64位程序。它的价值在于你在Windows下写C/C代码、跑开源项目、编译FFmpeg这种大型库时需要一个完整的GNU工具链而微软自己的MSVC编译器在很多开源生态里并不好用CMake、pkg-config、autotools这些工具链在MSVC下更是折磨人。所以MinGW64 MSYS2几乎成了Windows上捣鼓开源项目的标配。这篇文章要解决的事情很具体MinGW64到底是个什么东西为什么好几个人教你还把你教不会以及最关键的一步步实操包括一条命令装好MinGW64工具链顺带跑一次真正的MinGW64编译FFmpeg 4.4的完整流程。想复制我的操作跟着走就行想搞清楚“为什么这么装”这篇里面也会说清楚。2. MinGW64的家族史为什么这玩意儿这么乱2.1 从MinGW到MinGW-w64是标准的故事线最早大家用MinGWMinimalist GNU for Windows是为了在Windows上获得一个轻量级的GCC编译环境。原版MinGW只支持32位编译且多年不更新对64位Windows的支持糟糕透顶。后来社区分裂出一个新项目MinGW-w64它把GCC、binutils、Windows API的头文件库全部翻新了一遍同时支持32位和64位编译目标还把编译器底层的线程模型、异常处理模型做了现代化升级。现在你在网上搜“MinGW64”绝大多数情况下指的就是MinGW-w64而不是那早已进入博物馆的原版MinGW。很多人不理解为什么要关心这些区别因为自己明明只是“想装个gcc.exe能编译C语言”。但正是这种“不想关心区别”的心态才让你在下载MinGW64时被各种名称绕晕。实际上你在Windows下运行gcc.exe不管你用的是哪个发行版最终生成的.exe能否正常运行、能否跨平台分发完全取决于你在安装时选择的编译目标。而MinGW-w64下的编译目标具体到线程模型和异常处理模型直接决定了你写的C多线程代码在Windows上是不是好使。2.2 win32线程和posix线程这俩选错你就等着哭MinGW-w64安装时最容易看到也最让人懵的一对选择项就是线程模型win32还是posix。win32版本直连Windows原生线程API生成的代码更小巧、效率更高posix版本内置了POSIX线程兼容层目的纯粹是为了在Windows上也能用pthread、也能通过C11的标准线程库编译。如果你要用C标准库里的std::thread或者要交叉编译一些在Linux上写惯了的代码就必须选posix。选win32再写std::thread编译时直接给你报“thread不是std的成员”那场面和装完MinGW64一敲gcc就command not found一样让人崩溃。还有一个对应参数是异常处理模型64位工具链上基本都是SEH结构化异常处理32位则是SJLJsetjmp/longjmp或DWARF。这东西对一般用户的影响没有线程模型那么大但如果你编译的是32位程序且用了异常处理SJLJ和DWARF之间还是有兼容性差异的。说白了安装MinGW-w64的时候不要只看“最新版本”就往下点你得知道自己在装什么。2.3 三个主要安装来源必须得认清目前主流的MinGW64获取渠道有三条我分别说一下它们的定位省得你费半天劲装了一个错误的东西还不自知。第一条是SourceForge上MinGW-w64项目的离线包。这条路最老坑也最多。你下载下来的往往是一个“编译器本体”只有gcc、g、binutils这些核心工具没有包管理器没有依赖库的仓库。比如你想编译FFmpeg光有gcc没用你还得手动去一个个找x264、libmp3lame、libvpx这些外部库的二进制文件找到的还不一定对得上版本对齐不上就疯狂报链接错误。我自己第一回用FFmpeg就从这里栽过花两小时下工具链再花四小时找依赖最后还是在库上卡死。第二条是winlibs.com这类第三方发布的精简版MinGW-w64优点是真真正正的打开即用有条件的可以把整个工具链下下来丢到U盘里解压后配一下环境变量就行。缺点是它不提供依赖库管理也没有升级通道充其量只能算一个“便携编译器”对编个小程序、跑跑简单项目来说是省心的。第三条就是我最推荐你走的MSYS2方案。MSYS2不是一个单纯的MinGW64而是一个包管理器软件仓库多套工具链的大平台。你只需要到msys2.org下载一个安装包装完后打开MSYS2 MinGW64终端敲一条pacman命令就能把MinGW64 gcc工具链连同依赖库一起装整齐。因为它的库都是跟编译器配套编译好的很难出现架构不匹配、线程模型不统一这些问题。我这篇后面的安装实操全部以MSYS2为准。3. 从零安装MinGW64的完整实操3.1 第一步下载MSYS2而不是手动硬刚打开msys2.org下载最新的安装包安装文件名通常是msys2-x86_64-一个日期.exe一路Next安装。默认安装到C:\msys64你最好也保持默认路径因为后面有些工具脚本会在绝对路径里写死引用。安装完成后你会看到一堆启动方式MSYS2 MSYS、MSYS2 MinGW32、MSYS2 MinGW64、MSYS2 Clang64等一堆入口。这里必须强调一句编译64位程序一定开MSYS2 MinGW64终端因为MSYS终端默认用的是POSIX环境的工具链跟你刚开始选定的MinGW64是两码事。在MSYS2 MinGW64终端里先做一次全量更新把核心包和仓库信息刷到最新pacman -Syu如果更新过程中提示需要关闭终端就按提示来关掉再重新打开MSYS2 MinGW64终端再执行一次pacman -Su直到系统提示没有可更新的东西为止。这一步是很多教程忽略的坑不更新就直接装包容易出现依赖版本不匹配的诡异问题。3.2 第二步安装MinGW64工具链本体更新完成后在这个终端里敲pacman -S mingw-w64-x86_64-toolchain它会把gcc、g、gfortran、make、binutils、gdb、头文件、静态库等全部装好默认选择就是官方推荐的一组。这套组合拳下来你的Windows系统里就真正有了一套完整的64位GNU构建工具链。装完后验证一下gcc --version g --version which gccwhich gcc会显示类似/mingw64/bin/gcc的路径说明当前环境变量已经指向MSYS2的MinGW64。如果这里显示的是别的路径很大可能你的PATH里混进了某个旧版GCC或者Cygwin的配置先解决它再往下走。但这里有个关键坑你直接把gcc命令行打开CMD窗口输入是找不到的因为MSYS2的MinGW64环境变量只在这个MSYS2终端里生效Windows系统PATH里没有它。如果你想在任何终端都直接运行gcc需要去系统环境变量里把C:\msys64\mingw64\bin添加到PATH。我是不建议小白为了“能在cmd里用gcc”去改系统PATH的因为MSYS2的终端本身就够用改系统PATH还可能跟其他开发工具链发生干扰。当然要是你确实需要在VSCode之类的外部工具里使用那该加就加但要注意把MSYS2路径放在较靠前的位置避免被其他GCC覆盖。3.3 第三步给编译FFmpeg做准备装依赖单独只有工具链还谈不上“能编译FFmpeg”。FFmpeg 4.4构建时需要nasm或yasm汇编器来处理x86平台的汇编优化代码还需要pkg-config来识别第三方库。所以在MSYS2 MinGW64终端里再跑一行pacman -S mingw-w64-x86_64-nasm mingw-w64-x86_64-yasm mingw-w64-x86_64-pkgconfpkg-conf这个名字要特别划重点。FFmpeg的configure脚本在编译时会通过pkg-config查找libx264、libmp3lame这些库的头文件和链接参数。如果没有pkgconf或者pkgconf找不到库那么即使你把库装好了configure也会显示ERROR: libx264 not found。很多人编译FFmpeg卡在这一步不是库没装而是pkg-config这条线没通。如果想编译一个功能比较全的FFmpeg我是建议把这些常用依赖一次性装上不然configure的时候每报一个not found就要回来补装一次极其消磨耐心pacman -S mingw-w64-x86_64-x264 mingw-w64-x86_64-x265 mingw-w64-x86_64-libvpx mingw-w64-x86_64-libmp3lame mingw-w64-x86_64-opus mingw-w64-x86_64-libass mingw-w64-x86_64-freetype mingw-w64-x86_64-sdl2这几个包分别是H.264编码、H.265编码、VP8/VP9编码、MP3编码、Opus编码、字幕渲染、字形渲染和SDL输出。装齐以后你的编译环境已经比90%的Windows视频工具都完整了。4. 用MinGW64编译FFmpeg 4.4的完整实录4.1 下载源码与关键参数选择在MSYS2 MinGW64终端里先搞到FFmpeg 4.4源码。源码在ffmpeg.org官网的下载区能直接拿到也可以通过git拉取指定tag。我建议下载4.4的release包因为源码包内部的构建系统对新手更友善不需要额外处理git子模块的问题。比如说在你的工作目录下依次运行wget https://ffmpeg.org/releases/ffmpeg-4.4.tar.xz tar xf ffmpeg-4.4.tar.xz cd ffmpeg-4.4然后进入正题运行configure。这里我直接给出一份我实际在Windows下编译FFmpeg 4.4时用到的配置参数并且逐段解释为什么用它们./configure \ --prefix/mingw64 \ --archx86_64 \ --enable-static \ --enable-shared \ --enable-gpl \ --enable-libx264 \ --enable-libx265 \ --enable-libvpx \ --enable-libmp3lame \ --enable-libopus \ --enable-libass \ --enable-libfreetype \ --disable-doc \ --disable-debug--prefix/mingw64指的是编译安装后ffmpeg.exe、ffprobe.exe和库文件会被复制到MSYS2的/mingw64目录下也就是C:\msys64\mingw64。这样装完以后你在MSYS2 MinGW64终端里直接敲ffmpeg就能用不需要再改PATH。--enable-static和--enable-shared同时开的意思是你把所有库同时编译成静态库和动态库对于想生成独立exe的开发者用静态想做成DLL给别人调用的用动态这样一套编译得到两种产物。--enable-gpl必须开不然libx264、libx265这类GPL许可的库不会参与编译。后面的--enable-lib*就是明确告诉FFmpeg编译时要把这几个第三方库链接进来。4.2 编译阶段如何选make进程数configure跑完如果末尾没有出现红色Warning和Error那就进入编译阶段make -j4make的-j参数是并行编译的进程数。这里有个经验公式进程数接近CPU核心数但在Windows上最好不要顶满因为FFmpeg编译时的内存消耗非常疯狂尤其是链接阶段。我之前在一台8核16G内存的机器上跑make -j8内存直接干到15G系统卡成PPT最后直接OOM崩掉。之后我学乖了8核就开-j4大点的机器开-j6平稳得很。如果你用4核8G的本子推荐-j2起步编译时间多花20分钟换来的稳定性完全值得。整个FFmpeg 4.4的编译时间我在主流配置上跑大约25到40分钟。期间终端会刷出一堆警告比如warning: implicit declaration之类只要不是error就能继续。不少新手看到满屏warning就慌了其实大部分是编译器告警不影响最终产物。等到终端重新出现命令行提示符就意味着编译结束了。4.3 安装验证与产物交付编译完成后再执行make install安装过程很快主要是把二进制文件和库复制到/mingw64下面。然后验证ffmpeg -version ffprobe -version如果ffmpeg -version输出正常同时列出了一大串--enable-libx264这类编译配置就说明你的MinGW64编译FFmpeg 4.4大功告成。再进一步验证硬编码能力可以生成一个测试视频ffmpeg -f lavfi -i testsrcduration5:size640x360:rate30 -c:v libx264 -pix_fmt yuv420p test.mp4这条命令会利用FFmpeg自带的testsrc滤镜生成一段5秒的测试视频并编码为H.264如果最终test.mp4顺利生成那libx264编码这条路也通了。我自己编完以后还会有一步互操作测试用另一个机器或播放器打开这个test.mp4看是否正常。因为在MSYS2里编出来的exe有时会动态依赖libgcc_s_seh-1.dll、libstdc-6.dll等运行库把这些dll一起拷贝到目标机器上运行才稳妥。如果在免安装的场景下分发需要把C:\msys64\mingw64\bin里的这些运行库一并带过去或者编译时加上-static-libgcc -static-libstdc参数做全静态链接。5. 安装和编译过程中常见的坑逐个说透5.1 “gcc不是内部或外部命令”的三种常见解这句错误可以说是MinGW64新手第一个遇到的拦路虎。第一种解没有真正安装编译器只是下载了解压包没加PATH。检查C:\msys64\mingw64\bin\gcc.exe是否存在如果存在就去改系统环境变量PATH如果不存在就去MSYS2终端重新执行pacman安装命令。第二种解在错误的终端里运行命令比如打开的是MSYS2 MSYS终端那个终端的默认PATH是/usr/bin里面只有MSYS2自带的Clang/GCC前端不会调用/mingw64/bin下的编译器。解决办法非常简单打开MSYS2 MinGW64终端终端标题栏上会写清楚是MinGW64。第三种解系统PATH里同时存在另一个GCC比如Visual Studio或旧版Dev-C带的执行gcc --version后发现版本对不上那就需要到系统环境变量里把C:\msys64\mingw64\bin的顺序提到前面去。5.2 configure显示libx264 not found明明装了这个坑我在“mingw64编译ffmpeg4.4”这个热词下面看到特别多人踩。本质原因是pkg-config找不到MinGW64安装的库的.pc文件。检查方法很简单在MSYS2 MinGW64终端里执行pkg-config --modversion x264如果输出的是一串版本号说明pkg-config能看到该库如果报Package x264 was not found则说明搜索路径没覆盖到/mingw64/lib/pkgconfig。解决办法是把PKG_CONFIG_PATH环境变量指向正确目录export PKG_CONFIG_PATH/mingw64/lib/pkgconfig然后再重新运行configure。另外要确认一点你必须在MinGW64终端里装库而不是在MSYS终端里装了mingw-w64-x86_64-x264。因为MSYS终端虽然也是MSYS2的一部分但它和环境可能不同步。我见过有人因为开错终端pacman装出来的库是32位或MSYS格式的刚好和MinGW64编译器对不上configure自然一直找不到。一旦发现架构不匹配直接在MinGW64终端重装一遍mingw-w64-x86_64-x264就好。5.3 make时内存爆炸或者链接缓慢前面提到的内存问题这里再补充一个更稳的排查思路如果编译过程中报cc1plus: out of memory之类的错说明并行度实在太高。把make -j4降为make -j1编译时间会显著变长但绝不会再出现“卡死”的感觉。如果是在链接成巨型ffmpeg.exe时特别慢可以尝试只编ffmpeg、ffprobe这些命令行工具不要编全库的shared版本。实际使用中--enable-shared的链接开销很大必要时去掉它只静态输出产物放在单机上用没有任何问题。5.4 编译好的ffmpeg.exe提示缺少DLL这个属于分发范畴的坑。MinGW64编译出来的程序默认会链接GCC的运行时库而这些运行时库不一定存在于目标机器上。最简单的处理办法是找到刚才编译环境里那个目录C:\msys64\mingw64\bin把libgcc_s_seh-1.dll、libstdc-6.dll、如果有依赖还要带上libwinpthread-1.dll全部放在exe同目录下。如果不太想带一堆dll也可以在configure之前给FFmpeg的CFLAGS和LDFLAGS里加上-static-libgcc -static-libstdc。说实话对于个人使用带着dll更省事对于给第三方分发静态链接更不容易出问题。5.5 MSYS2仓库里FFmpeg已经有了为什么还要自己编这是一个进阶问题但值得一说。MSYS2仓库里确实有现成的mingw-w64-x86_64-ffmpeg包一条pacman命令就能装好现成的ffmpeg.exe。那为什么还要自己折腾源码编译最主要的原因是控制编译选项仓库里的版本通常只开启了最基本的编解码库很多商用或小众功能没有编译进去自己编可以任意加减功能比如额外集成自定义的libx264补丁、加上--enable-libsvtav1的AV1编码等。其次是自己编译还能内嵌指定的FFmpeg版本比如你需要在4.4这个老版本上工作而仓库里早更新到6.x了那就只能自己编。这类需求在开发FFmpeg滤镜插件、跑老项目构建脚本时特别常见。错误特征最可能的原因处理思路gcc不是内部或外部命令PATH未配置或在错误终端检查bin路径是否在PATH中切换到MinGW64终端libx264 not foundpkg-config未找到.pc文件设置PKG_CONFIG_PATH/mingw64/lib/pkgconfigout of memory并行编译过高降为make -j1或-j2缺少DLL动态运行库未分发拷贝libgcc_s_seh-1.dll等运行库或静态链接6. 我在多次折腾MinGW64后留下的几条经验6.1 最关键的一条用包管理器管理一切真正把MinGW64搞顺之后我再回头去看“不会安装MinGW64”这句话其实就是最开始不知道三个选择题的答案选哪个发行版、选哪个线程模型、在哪个终端里跑命令。把这三点整理清楚剩下就全是执行层面的事情跟踩坑斗勇没什么关系。我个人从几次痛苦经历里得到最实用的一条建议是不要跟着一篇老博客去SourceForge手动下载那个不更新的离线安装器直接去MSYS2官网让pacman来管理工具链和依赖库。包管理器这个设计太重要了它把“缺什么库就装什么库”这件事变成了一个命令的事。如果你只是想在VS Code里写写C、顺手编译几个小项目MSYS2的MinGW64方案基本上就是Windows上体验最好的那一档。6.2 顺手做一个绿色版FFmpeg包最后再分享一个小技巧编译完FFmpeg后把make install完的/mingw64/bin里的ffmpeg.exe、ffprobe.exe复制到一个单独的文件夹然后拷走那份目录下的所有依赖dll这样你就得到了一个纯绿色的FFmpeg包。以后在任何一台Windows机器上解压就能直接用不用再装任何环境。这个习惯帮我省了无数个“为什么你机器上能跑我机器上不能跑”的扯皮时间。折腾工具链这种事第一次都会疼但把环境彻底搞顺之后回报会很持久。