MinGW-w64与GCC 4.9.2实战：64位Windows下编译DLL全指南

简介：面向Windows程序员、学生及需要从Linux迁移到Windows的开发者，这是一份MinGW-w64 4.9.2工具链包，内含GCC 4.9.2编译器，专门用于64位环境下的C/C++程序编译、链接与调试，有效解决Windows平台缺少原生GNU编译工具链的痛点，适合构建原生64位应用、学习GNU工具链机制或为跨平台项目做编译验证。压缩包共3541个文件，以h头文件（1702个）和a静态库（1280个）为主体，前者提供标准API声明，后者便于链接依赖，另有hpp头文件、exe可执行文件、o目标文件等，覆盖标准库声明、静态链接库和编译驱动工具，包体约35MB，解压后配置环境变量即可投入开发，目录结构清晰，可离线查阅标准库实现并直接引用所需库文件。已有1508人学习，是CSDN上较为实用的编译环境资源。开发者可借助其中完整的gcc/g++编译驱动、GDB调试器支持以及Makefile自动化构建能力，快速搭建本地工具链；配合POSIX线程模型和内置的静态库，既能编译运行基础示例，也能支撑大型项目的源码编译与调试，在64位Windows下生成高性能可执行程序，整体使用体验接近GNU/Linux开发环境，是一个开箱即用、无需额外配置的完整工具链。

1. 这个组合到底是什么情况

MinGW 64位配 gcc 4.9.2，放到今天看有点老古董的味道，但真正常年跟嵌入式、Windows 原生编译打交道的朋友，应该都没少跟它打交道。MinGW 是 Windows 平台上的一层 GCC 移植环境，它让 gcc、g++、gdb 这些 GNU 工具链能在 Windows 上原生运行，生成不依赖额外运行时库的 Windows PE 可执行文件。而 gcc 4.9.2 是 2014 年左右发布的版本，属于 GCC 4.9 系列的中期修订版，对 C++11 的支持已经比较完整，也没有 5.x 系列刚切换新 ABI 时那种库不兼容的历史包袱。

我最早接触这个组合，是因为某家芯片厂商的 SDK 强制要求“Windows 64 位 + gcc 4.9.2”来编译底层驱动和静态库。后来做老项目维护，也遇到一些只在 4.9.x 下编译正常的遗留 C++ 代码，用新版 gcc 一跑就是一堆 ABI 相关的报错。所以这个组合的核心价值不是“新”，而是“兼容”——它处在 C++03 到 C++11 的过渡地带，老代码能过，新代码只要不碰 C++14/17 的特性也能编译，加上 64 位支持解决了 2GB 内存上限问题，让它成了很多工具链、SDK 和交叉编译环境的事实标准。

这篇文章想说的东西很明确：如果你手里有老 SDK、老交叉工具链，或者在 Windows 上要编译 64 位 C/C++ 库、DLL，甚至被 CUDA 老版本绑定了 gcc 版本，那么“MinGW 64位 + gcc 4.9.2”这套环境值得仔细搞明白。我会把这套环境的搭建、版本校验、架构判断、DLL 编译实战和常见坑全部捋一遍，尤其是那些网上答得模棱两可的问题，这次一次性说透。

2. 环境准备：装一套能用的 64 位 gcc 4.9.2

2.1 优先选 MinGW-w64，别用老 MinGW.org

先说结论：需要 64 位 gcc 4.9.2 的时候，直接找 MinGW-w64 项目的历史版本，别去 MinGW.org 官网下那个经典安装器。MinGW.org 的老版本安装器默认只到 32 位，而且它的版本迭代早就停住了，装出来的 gcc 也基本不是 4.9.2。MinGW-w64 是从 MinGW 分化出来的独立项目，从诞生那天就同时支持 32 位和 64 位交叉编译，gcc 4.9.2 这个时间点上已经有对应的 MinGW-w64 构建版本可用，日常说的“用 gcc 4.9.2 的 64 位 Windows 工具链”，基本都落在这个发行版上。

我自己的经验是，与其去官网找那种需要在线安装的“网络安装器”，不如找已经打包好的压缩包工具链。这类压缩包通常几十到一百多兆，解压即用，里面含 gcc、g++、mingw32-make、gdb、ar、ranlib 这些常用工具，连 GNU 的工具链配套头文件和导入库都是齐的。下载时记得看构建配置里的线程模型（posix 或 win32）和异常处理模式（seh 或 sjlj），gcc 4.9.2 时代大部分 Windows 工具链默认是 win32 线程 + sjlj 异常，少数构建是 posix 线程 + seh。选 posix 的好处是能在 Windows 下用 std::thread 这类 C++11 线程库，win32 模型则对老代码更保守。如果只是编译普通 C/C++ 代码，两种都能用，差别主要在 C++ 标准库的线程支持上。

2.2 手动配置环境：三步走，别偷懒

工具链压缩包解压到某个非中文路径下，比如D:\dev\mingw64，接下来要做的就是让系统能找到这些工具。我建议手动配置，不用那些自动设置环境变量的小工具，因为自己清楚改了哪些地方，以后排查问题心里有数。

第一步，右键“此电脑” → 属性 → 高级系统设置 → 环境变量，在“系统变量”里找Path，把D:\dev\mingw64\bin追加进去。注意目录层级，bin文件夹里才是 gcc.exe、g++.exe，不要指到D:\dev\mingw64就结束。

第二步，新建一个系统变量叫LIBRARY_PATH，或者直接省事不建，但推荐建一个指向D:\dev\mingw64\lib，这样后续编译部分第三方库时，链接器能更容易找到导入库和静态库。

第三步，新建系统变量C_INCLUDE_PATH指向D:\dev\mingw64\include，CPLUS_INCLUDE_PATH指向D:\dev\mingw64\include\c++\4.9.2以及对应的平台子目录。不设置这两个变量，写大工程时系统头文件搜索路径容易出问题，尤其是用到 C++ 标准库头文件时。

配置完别急着关终端，重新开一个 cmd 或 PowerShell，输入下面三行验证：

gcc -v gcc -dumpversion echo %PATH%

gcc -v能看到完整的版本号和配置选项，gcc -dumpversion直接输出 4.9.2，如果这里输出的是别的版本，说明 PATH 里还有另一个 gcc 抢先了，这就是网上热词里“gcc 升级后为啥还是旧版本”的典型场景，后面第 3 部分会专门讲。

2.3 MSYS2 的坑与替代方案

现在很多人一搜“MinGW 安装”，搜到的是 MSYS2。MSYS2 是个好东西，它自带 pacman 包管理器，能用pacman -S mingw-w64-x86_64-gcc装一套全新的 gcc，但如果你的目标就是 gcc 4.9.2 这个特定版本，MSYS2 默认源里可能找不到。它更倾向于维护新版 gcc，老版本需要翻历史包或者根本不提供，强行装完也会遇到 pacman 把版本升级掉的问题。

MSYS2 还有一点容易让人踩坑：它自带了一套 POSIX 模拟层（msys-2.0.dll），如果直接用 MSYS2 里的 gcc 编译出来的程序，有时会依赖 MSYS2 运行时，丢到别的 Windows 机器上就报缺 DLL，比如“api-ms-win-shcore-scaling-l1-1-1.dll”这类系统组件缺失。这不是 gcc 的问题，是运行时环境没打全或目标机器系统版本太旧。对于要分发 exe、dll 的场景，我更推荐直接用 MinGW-w64 压缩包工具链，编译产物对系统 DLL 的依赖一目了然，不容易被别人反复问“为什么我这跑不起来”。

我这里说的 MinGW 64位 gcc 4.9.2，实际指的是 MinGW-w64 的 gcc 4.9.2 版本。如果你在工具链压缩包里找目录，会发现它的文件夹结构是mingw64\bin、mingw64\lib、mingw64\include，跟 MSYS2 里的名字一样，但依赖关系干净得多。

3. 版本与架构排查：升级后还是旧版本、32/64 位如何判断

3.1 升级后为啥还是旧版本？大部分是 PATH 顺序问题

这个现象太经典了：明明刚把新版 gcc 解压配置好，结果终端里一敲gcc -v，还是旧版本号。多数情况不是没装上，而是系统 PATH 里同时存在多个 gcc，命令解析时先找到了旧的那一个。

Windows 执行命令时按 PATH 里目录的前后顺序查找，谁排在前面谁先被找到，不会自动选“版本最新”的那个。比如你装了 TDM-GCC 在C:\TDM-GCC-64\bin，又把 MinGW-w64 的D:\dev\mingw64\bin追加在了后面，那敲 gcc 时系统永远先去 C 盘那个目录找，自然就是旧版本被调用。

排查方法很简单，在终端里用：

where gcc

这条命令会把 PATH 里所有能找到的 gcc.exe 完整路径列出来，顺序就是查找顺序。看到第一行不是自己预期的路径，就把环境变量里的 Path 顺序调整一下，或者干脆把不需要的旧 gcc 目录从 PATH 中移除。还有个细节，改完环境变量后要重开终端窗口，否则环境变量不刷新，这也是很多人改了却以为没生效的原因。

3.2 如何查看一个 .a 库或 .dll 是 32 位还是 64 位

老项目里经常要跟“历史遗留”静态库打交道，接第三方库时如果不知道它是 32 还是 64 位，链接阶段会报奇怪的错误，比如“skipping incompatible ... when searching for -lxxx”。这里有两种最直接的判断方法。

第一种，用file命令。MinGW-w64 工具链里自带file.exe，在 bin 目录下，用它看库文件：

file libfoo.a file foo.dll

输出会明确写“current ar archive”或“PE32 executable (DLL) (console) x86-64”之类，PE 文件会直接标 x86（32 位）还是 x86-64（64 位）。

第二种，用手边现成的 gcc 自带工具objdump：

objdump -f libfoo.a objdump -f foo.dll

看输出里的“architecture”字段，i386 就是 32 位，x86-64 就是 64 位。这个方法更通用，因为 objdump 是 GNU binutils 的标配，MinGW-w64 压缩包里一定有。

还有个小技巧，直接看库文件的文件头格式。一个 64 位 Windows 下的 DLL 文件，开头两个字节是字母“MZ”，偏移到 0x3C 位置存放 PE 头偏移，再到 PE 头里能看到 Machine 字段，0x14C 代表 i386（32 位），0x8664 代表 x86-64（64 位）。手边没有工具时，用十六进制编辑器查这几个字段也能判断。但日常用 file 或 objdump 就够了，这个手工验证方法适合应急。

3.3 regsvr32 在 64 位系统注册控件失败

这个坑不算 gcc 的锅，但经常出现在大家打包 DLL/OCX 的流程里。在 64 位 Windows 上，regsvr32.exe 有两个版本：系统目录C:\Windows\System32\regsvr32.exe是 64 位，C:\Windows\SysWOW64\regsvr32.exe是 32 位。如果你拿 64 位的 regsvr32 去注册一个 32 位的 COM 组件，会直接报错，反过来也一样。

所以注册 DLL 时，先把编译器位数和 DLL 位数对上号，再选对应位数的 regsvr32。命令行里分别用：

# 注册 64 位 DLL，用 64 位 regsvr32 C:\Windows\System32\regsvr32.exe C:\path\to\your_64.dll # 注册 32 位 DLL，用 32 位 regsvr32 C:\Windows\SysWOW64\regsvr32.exe C:\path\to\your_32.dll

注意这里“SysWOW64”名字看起来像 64 位目录，实际里面是 32 位系统文件。这个命名反直觉，很多人栽过。如果你的 DLL 是用 MinGW-w64 64 位 gcc 编出来的，记得一定要用 System32 下那个 regsvr32。

3.4 64 位模式下调用 32 位 DLL 的问题

Windows 并没有提供简单的“64 位进程直接调用 32 位 DLL”的机制，这是系统层面的硬隔离，而不是 gcc 的问题。如果你在 64 位程序里试图 LoadLibrary 一个 32 位 DLL，会得到 ERROR_BAD_EXE_FORMAT 或者“%1 不是有效的 Win32 应用程序”。

之前有人问“用 gcc 编出的 so 差异会大吗”，Windows 上虽然没有 .so，但对应到 .dll 是一样的道理：32 位和 64 位 DLL 是两套完全不同的 PE 格式，导出函数名、调用约定细节、指针宽度都不同，不能混用。要是确实需要 64 位进程中调用 32 位功能，实际工程中通常是把 32 位 DLL 封装成一个独立的 32 位 exe 进程，再用进程间通信去调，或者把 32 位核心代码重新编译成 64 位版本，二选一。用 MinGW-w64 64位 gcc 4.9.2 编译时，这点尤其要提前想清楚，不然做 DLL 的接口设计会白忙活。

4. 实战：用 gcc 4.9.2 编一个 DLL 给跨语言调用

4.1 从一段 C 代码生成 DLL 全过程

很多项目里会遇到“上层用 C#/Python/Java，底层用 C/C++ 编 DLL”的情况。用 MinGW-w64 64 位 gcc 4.9.2 生成 DLL，和 MSVC 的流程不一样，但掌握了反而更简单，它不需要写 .def 文件，也不用额外设置__declspec(dllexport)之外的东西（导出函数还是要声明的）。

先写一个最简单的示例，文件名叫mylib.c。这个例子会导出一个加法和一个字符串处理的函数，方便验证导出和调用：

#include <windows.h> #ifdef __cplusplus extern "C" { #endif __declspec(dllexport) int add(int a, int b) { return a + b; } __declspec(dllexport) const char* get_message(void) { return "Hello from MinGW GCC 4.9.2"; } BOOL WINAPI DllMain(HINSTANCE hinstDLL, DWORD fdwReason, LPVOID lpvReserved) { (void)hinstDLL; (void)fdwReason; (void)lpvReserved; return TRUE; } #ifdef __cplusplus } #endif

编译命令：

gcc -shared -o mylib.dll mylib.c -Wl,--out-implib,libmylib.a

逐段解释每个参数是干什么的，这个比背命令更重要：

• -shared：告诉 gcc 生成 DLL 而不是 exe。
• -o mylib.dll：指定输出文件名。
• -Wl,--out-implib,libmylib.a：链接器选项，让 gcc 在生成 DLL 的同时导出导入库（import library）。这个.a文件是给后续用 MinGW 编译其他程序时链接用的，相当于 MSVC 的.lib。

编译完目录下会有两个文件：mylib.dll和libmylib.a。前者给运行时动态加载，后者给编译链接时解析符号。

4.2 用 dumpbin 和 objdump 验证导出符号

编完 DLL 之后，建议立刻验证导出符号是不是符合预期。这一步很重要，因为少了它，后面跨语言调用经常在运行时才报“找不到入口点”之类的错。

用 gcc 工具链自带的 objdump：

objdump -p mylib.dll | grep -A5 "Export Table"

或者更直接，看 DLL 导出的函数名：

objdump -p mylib.dll | grep "add\|get_message"

如果你机器上装了 Visual Studio，也可以用 dumpbin：

dumpbin /exports mylib.dll

正常的输出里应该能看到add和get_message这两个名字。注意，如果编译时没有加extern "C"而文件后缀名又是 .cpp，导出符号会被 C++ name mangling 处理，变成类似?add@@YAHHH@Z这种名字，跨语言调用时非常麻烦。所以上面示例代码用 .c 后缀并且加上extern "C"是有意为之的，这是经验，不是巧合。

C# 调用这个 DLL 可以这样写 DllImport：

[DllImport("mylib.dll", CallingConvention = CallingConvention.Cdecl)] public static extern int add(int a, int b); [DllImport("mylib.dll", CallingConvention = CallingConvention.Cdecl)] public static extern IntPtr get_message();

这里CallingConvention.Cdecl对应 gcc 的默认调用约定。如果你用 gcc 编译却不指定调用约定，默认是 cdecl，C# 那边不声明清楚就容易导致栈平衡错误。这个细节看着小，实际调试时能浪费一晚上。

4.3 64 位 DLL 和 32 位 DLL 的编译差异

同一份代码，编译 64 位 DLL 和 32 位 DLL 的差别主要在两点。

一是编译器本身。用 MinGW-w64 的 64 位工具链编出来的默认是 64 位 PE，32 位版本需要 i686 分支的工具链，或者加-m32参数交叉编译（前提是你装了 multilib 支持）。gcc 4.9.2 时代的多库支持其实是够的，但压缩包工具链是否带 multilib 得看构建方。

二是编译参数上的指针大小和结构体对齐。64 位下指针是 8 字节，long 在 Windows 的 LP64 与 MSVC 中都是 4 字节，但size_t、long long这些在 64 位下全是 8 字节。如果你写 DLL 导出接口时要跨语言调用，最好把跨边界传递的整数类型明确写成int32_t、uint64_t这种定长类型，不要写long，因为 MSVC 和 MinGW 的 long 长度策略在某些平台上有历史差异，容易在互操作时出错。

编译命令上的差异，简单说就是 64 位不用改代码，但要确保拿的是 x86_64 的 gcc（在终端里验证过是 4.9.2 且位数正确）。如果你在 64 位系统上编译一个 32 位 DLL，然后用 32 位程序去调用，对应的 DLL 就不能混用，目录结构也建议区分，比如bin64和bin32，避免部署时搞混。

4.4 编译 SDL 这类依赖库时的经验

网上热词里有“gcc link sdl”，这也是 MinGW 场景下的常见需求。老的 SDL 项目要求在 Windows 下用 gcc 编译，链接命令行大致是：

gcc -o game.exe game.c -IC:\SDL2-2.0.10\x86_64-w64-mingw32\include -LC:\SDL2-2.0.10\x86_64-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2

注意几个关键点：

• SDL2 官方发布的 MinGW 开发库是区分 32/64 位的，下载时看目录名x86_64-w64-mingw32或i686-w64-mingw32，别下错。
• -lmingw32和-lSDL2main的顺序不能乱放，SDL 官方给的 LDFLAGS 里这组顺序是固定的，乱换会报一堆未定义引用。
• gcc 4.9.2 对 SDL2 的编译完全够用，SDL2 的新版本 API 并不依赖高版本 gcc，反而老版本 gcc 编出来的 SDL 程序在一些老 Win7 上跑得还更稳。

这套命令我实测过很多次，只要 SDL 库位数和 gcc 位数一致，基本一次通过。容易出问题的反而是之前提到的 PATH 顺序，有时候 SDL 库目录里带了SDL2.dll，程序运行时没把它复制到 exe 同目录，就会报缺 DLL 错误。这跟 gcc 无关，但经常被新同学扣在“MinGW 编不出能跑的 exe”这个锅上。

5. 常见的坑与解决方案速查表

这部分我把这些年积累的高频问题整理成一个速查表，方便你在实际项目里快速定位。表格里的内容，大部分都是我在命令行里踩过之后才明白的。

上面表格最后一条说的异常模型，值得再展开一下。MinGW-w64 的 64 位构建在 gcc 4.9.2 时期有两种异常处理实现：seh 和 sjlj。seh 基于 Windows 结构化异常处理，性能更好；sjlj 是传统的 setjmp/longjmp 方案，兼容性更稳。如果编译时遇到奇怪的“unwind”相关报错，或者链接时找不到 libgcc 里的某些函数，多半是工具链里异常模型混了。我个人的建议是：从一而终，选一个工具链版本，不要同时在 PATH 里放两套不同异常模型的 MinGW，否则第三方库编译的 C++ 部分很容易出妖蛾子。

6. 还想补充的两个小技巧

最后再分享两个平时不太容易被文档提到的小技巧，都跟 MinGW-w64 64 位 gcc 4.9.2 相关。

第一个是看编译产物到底依赖哪些系统 DLL。用 MinGW 编出来的 exe，理论上比 MSVC 版本更“省心”，但仍然可能依赖 libgcc_s_seh-1.dll、libstdc++-6.dll、libwinpthread-1.dll 这几个运行时 DLL。分发程序时想把它们一起带出去，最省事的办法是编译时加静态链接选项：

gcc -o app.exe app.c -static-libgcc -static-libstdc++

如果是单线程程序，还可以加-static把整个运行时静态链进去，产物会大一圈但依赖最少。

第二个是查看一个 exe/dll 是 32 还是 64 位，也可以直接看文件头 Machine 字段。用 objdump 更直接，但如果只能用手边现成的工具，在 PowerShell 里读文件头也可以：

$bytes = [System.IO.File]::ReadAllBytes("C:\path\to\your.dll") $peOffset = [BitConverter]::ToInt32($bytes, 0x3C) $machine = [BitConverter]::ToUInt16($bytes, $peOffset + 4) if ($machine -eq 0x8664) { "64-bit" } elseif ($machine -eq 0x14c) { "32-bit" }

实测下来跟 objdump 结果一致，应急时非常方便。

这套“MinGW 64位 gcc 4.9.2”环境，说新不新，说老也不算彻底过时，在特定领域里一直是好用又可靠的工具链。在我手里，它帮我把几个老到不敢碰的历史项目从“只能编译 32 位”提升到了“64 位稳定运行”，也让不少跨语言调用的 DLL 模块顺利跑通。如果你正卡在版本号不对、库位数不符、DLL 调用失败这类问题上，按上面这些步骤挨个排查，大概率能省下不少折腾的时间。

本文还有配套的精品资源，点击获取