简介：MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源，适合在本地学习 C++、希望摆脱大型 IDE 依赖的开发者与编程初学者。它提供命令行编译环境，可快速完成代码编译与调试，帮助理解从源码到可执行文件的完整过程。压缩包为 zip 格式，整体约 156.05MB，包内以 GCC 编译器、libstdc++ 标准库、Binutils 链接与汇编工具、Make 构建工具及头文件、静态/动态库等开发组件为主，覆盖 C++11、C++14、C++17 标准及部分 C++20 特性。资源中的 TDM-GCC-64 是 MinGW 针对 64 位 Windows 优化的分支，集成较新的 GCC 版本与库，可生成并运行 64 位应用程序。目前已有 115 人学习下载，适合需要轻量级本地编译环境、想体验 GCC 稳定性与标准支持的 C++ 学习者参考使用。1. MinGW for Win64：把 Linux 风格的 C++ 工具链搬到 Windows 上如果你在 Windows 上写 C++，却不想装几个 GB 的 Visual Studio，又希望g++、gdb、make这些命令能像在 Linux 上一样随手就用，那 MinGW for Win64 就是为你准备的。它本质上是把 GCC 工具链裁剪并移植到 Windows 64 位环境，让你在原生 Windows 下编译出.exe，不需要模拟层，也不需要 WSL。我见过太多人卡在“装完不会配环境变量”或者“编译出来缺 DLL”这两步上，其实只要搞清楚它的目录结构和链接模型，十分钟就能跑通第一个程序。这份资源适合三类人：刚学 C++ 不想被 IDE 绑架的新手、需要交叉编译 Windows 目标的老手、以及想用 CMake + GCC 组合做持续集成的开发者。2. 拆开目录看门道：bin、lib、include 各管什么2.1 工具链的四个核心目录拿到 MinGW for Win64 的压缩包，解压后你会看到类似mingw64的根目录。别急着配 PATH，先花两分钟看清楚里面有什么。常见结构是bin、lib、include、libexec四个目录，外加一个share放文档。bin里是可执行文件，包括gcc.exe、g++.exe、gdb.exe、mingw32-make.exe、windres.exe等。lib里是静态库和导入库，比如libstdc++.a、libgcc.a、libwinpthread.a。include是 C 和 C++ 标准库头文件，以及 Windows API 的兼容头文件。libexec里是 GCC 内部调用的子程序，比如cc1plus.exe，你平时不会直接碰它，但缺了它编译就会报“cannot execute cc1plus”。我一般会先确认bin下有没有g++.exe和gcc.exe，再用g++ --version看版本号。如果输出里带x86_64-w64-mingw32字样，说明这是 64 位目标。注意，有些打包版本会把 32 位和 64 位混在一起，bin下同时有gcc.exe和x86_64-w64-mingw32-gcc.exe，后者才是明确针对 Win64 的。如果你直接调gcc，可能默认走 32 位，链接时就会报架构不匹配。2.2 环境变量怎么配才不打架配置 PATH 是最容易翻车的地方。假设你解压到了D:\tools\mingw64，那么需要把D:\tools\mingw64\bin加到系统 PATH 的最前面。为什么强调最前面？因为 Windows 上可能已经装了其他编译器，比如 MSYS2 的 GCC 或者旧版 MinGW，如果它们的路径排在前面，你敲g++调到的就不是这份资源里的版本。我习惯在 PowerShell 里用$env:Path临时验证：# 临时把 MinGW 的 bin 放到 PATH 最前，只对当前会话生效 $env:Path = "D:\tools\mingw64\bin;" + $env:Path # 确认调用的 g++ 路径和版本 where.exe g++ g++ --version第一行把新路径拼到最前面，第二行where.exe会列出所有匹配的g++，排在第一的就是当前生效的。第三行看版本输出，如果显示x86_64-w64-mingw32且版本号符合预期，说明配置正确。永久生效需要去“系统属性 → 环境变量”里编辑 Path，把D:\tools\mingw64\bin上移到最顶。注意不要同时把bin和mingw64根目录都加进去，那样容易让某些脚本找不到相对路径。2.3 第一个编译命令与链接参数环境配好后，写一个最简单的hello.cpp：// hello.cpp #include <iostream> int main() { std::cout << "MinGW for Win64 works!" << std::endl; return 0; }编译命令我一般用：g++ hello.cpp -o hello.exe -static-libgcc -static-libstdc++这里-o hello.exe指定输出文件名，-static-libgcc和-static-libstdc++是关键。默认情况下，MinGW 动态链接libgcc_s_seh-1.dll和libstdc++-6.dll，如果你把hello.exe拷到没装 MinGW 的机器上，就会弹窗报“找不到 libstdc++-6.dll”。加上这两个静态链接选项后，生成的 exe 不依赖这些 DLL，体积会大几十 KB，但换来的是单文件可分发。如果你确实想动态链接，那就得把bin下的对应 DLL 一起拷走，或者用-Wl,-rpath指定相对路径，但在 Windows 上 rpath 支持有限，不如静态链接省心。3. 从单文件到多文件：make 与 CMake 的落地配置3.1 用 mingw32-make 跑通 MakefileMinGW for Win64 自带的是mingw32-make.exe，不是make.exe。你可以手动改名为make.exe，也可以直接用它。写一个三文件的工程：main.cpp、math_utils.cpp、math_utils.h。Makefile 可以这样写：# Makefile for MinGW for Win64 CXX = g++ CXXFLAGS = -std=c++17 -Wall -O2 -static-libgcc -static-libstdc++ TARGET = app.exe OBJS = main.o math_utils.o $(TARGET): $(OBJS) $(CXX) $(OBJS) -o $(TARGET) $(CXXFLAGS) %.o: %.cpp $(CXX) $(CXXFLAGS) -c $< -o $@ clean: del /Q $(OBJS) $(TARGET)注意clean里用的是del /Q，这是 Windows 命令，不是 Linux 的rm -f。如果你在 Git Bash 里跑 make，del会找不到，得改成rm -f。我一般会在 Makefile 开头判断系统，但为了简单，直接写del并在 cmd 或 PowerShell 里执行mingw32-make最稳。CXXFLAGS里的-std=c++17指定标准，-Wall开警告，-O2优化。%.o: %.cpp是模式规则，$<表示依赖文件，$@表示目标文件。执行mingw32-make后，你会看到先编译两个.o，再链接成app.exe。3.2 CMake 生成 MinGW MakefilesCMake 是更现代的选择。假设你有一个CMakeLists.txt：cmake_minimum_required(VERSION 3.15) project(MinGW64Demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 强制静态链接 libgcc 和 libstdc++ set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++") add_executable(app main.cpp math_utils.cpp)在项目根目录下建一个build文件夹，然后执行：cd build cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release .. mingw32-make-G "MinGW Makefiles"告诉 CMake 生成给mingw32-make用的构建文件。如果你不加这个参数，CMake 可能默认找 Visual Studio 生成器，结果报错说找不到cl.exe。-DCMAKE_BUILD_TYPE=Release会启用-O3 -DNDEBUG。CMAKE_EXE_LINKER_FLAGS里加静态链接选项，保证生成的 exe 不依赖 MinGW 的 DLL。执行完mingw32-make后，build目录下会出现app.exe。我习惯在CMakeLists.txt里再加一句set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)，把 exe 统一放到bin下，方便打包。3.3 调试信息与 gdb 的配合编译时加-g才能用 gdb 调试。比如：g++ -g -O0 main.cpp math_utils.cpp -o app_debug.exe gdb app_debug.exe进入 gdb 后，break main设断点，run启动，next单步，print 变量名看值。MinGW for Win64 自带的 gdb 通常支持 Python 脚本，但如果你遇到During startup program exited with code 0xc0000135，多半是缺 DLL。因为 gdb 本身也依赖libstdc++-6.dll等，如果你把bin从 PATH 里移除了，gdb 就起不来。所以调试时确保 PATH 里有 MinGW 的bin。另外，-O0关闭优化，否则断点可能跳来跳去，变量被优化掉，这就是所谓的“玄学调试”。4. 避坑与排查：五个让你少熬两晚的踩坑记录4.1 现象：编译报 “undefined reference to__imp_WinMain@16”原因：链接器找不到入口点。常见于你写了int main()但编译时用了-mwindows，或者反过来，你写了WinMain却按控制台程序链接。MinGW for Win64 默认入口是mainCRTStartup，对应main。如果你在 CMake 里加了WIN32关键字，CMake 会传-mwindows，此时需要WinMain。解决：控制台程序不要加-mwindows，GUI 程序确保函数签名是int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)。检查 CMake 的add_executable(app WIN32 ...)是否误加。4.2 现象：exe 在别的电脑上弹窗“找不到 libstdc++-6.dll”原因：动态链接了 GCC 运行时库，目标机器没装 MinGW。解决：编译时加-static-libgcc -static-libstdc++，或者用-static全静态链接。注意-static可能导致某些 Windows API 库冲突，一般只加前两个就够。如果还缺libwinpthread-1.dll，再加-static -lpthread或-Wl,-Bstatic -lwinpthread -Wl,-Bdynamic。4.3 现象：mingw32-make报 “make: *** No rule to make target 'xxx.o'”原因：Makefile 里的模式规则没匹配上，或者源文件扩展名不是.cpp。常见于你把文件存成了.c但用g++编译，或者路径里有空格。解决：确认源文件后缀与规则一致。路径有空格时，用引号包起来，或者在 Makefile 里用$(wildcard *.cpp)自动收集。我一般把项目放在没有空格的路径下，比如D:\work\demo。4.4 现象：gdb 启动报 “During startup program exited with code 0xc0000135”原因：gdb 依赖的 DLL 不在 PATH 里，或者你编译的 exe 依赖的 DLL 缺失。解决：把D:\tools\mingw64\bin加到 PATH 最前，重新开一个终端。用where.exe libstdc++-6.dll确认能找到。如果还不行，用ldd app.exe（MinGW 自带ldd.exe）看缺哪个 DLL，手动拷到 exe 同目录。4.5 现象：CMake 配置时报 “CMAKE_CXX_COMPILER not set”原因：CMake 没找到g++，或者你用了-G "Visual Studio"但没装 VS。解决：在build目录下先cmake -G "MinGW Makefiles" ..，并确保g++在 PATH 里。如果之前配置过其他生成器，删掉build下的CMakeCache.txt再重来。我习惯每次换生成器都清空build目录，避免缓存干扰。5. 进阶技巧：用 windres 加图标与版本信息5.1 准备 .rc 文件与图标MinGW for Win64 自带windres.exe，可以把 Windows 资源编译进 exe。新建app.rc：#include <windows.h> IDI_ICON1 ICON "app.ico" VS_VERSION_INFO VERSIONINFO FILEVERSION 1,0,0,0 PRODUCTVERSION 1,0,0,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "FileDescription", "MinGW64 Demo" VALUE "FileVersion", "1.0.0.0" VALUE "ProductName", "Demo App" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END ENDIDI_ICON1 ICON "app.ico"指定图标文件，VERSIONINFO块定义版本信息。040904b0表示英语美国、Unicode。Translation里的0x409是语言 ID，1200是代码页。5.2 编译资源并链接先用windres编译.rc为.o：windres app.rc -O coff -o app_res.o-O coff指定输出 COFF 格式，这是 MinGW 链接器能识别的。然后链接时把app_res.o加进去：g++ main.cpp math_utils.cpp app_res.o -o app.exe -static-libgcc -static-libstdc++如果你用 CMake，可以这样写：set(RES_FILES app.rc) add_executable(app main.cpp math_utils.cpp ${RES_FILES})CMake 会自动调用windres处理.rc文件。生成的app.exe在资源管理器里会显示你设置的图标，右键属性也能看到版本信息。这个技巧在交付给客户时特别有用，不然一个默认的空白图标显得很敷衍。5.3 验证与分发检查清单编译完成后，我习惯做三件事：第一，用objdump -p app.exe | findstr "DLL Name"看依赖了哪些 DLL，确保没有libstdc++-6.dll和libgcc_s_seh-1.dll。第二，把 exe 拷到一个干净的虚拟机或另一台没装 MinGW 的电脑上双击运行。第三，用sigcheck或 PowerShell 的Get-Item app.exe | Select-Object VersionInfo看版本信息是否写入成功。如果依赖列表里还有libwinpthread-1.dll，就在链接时加-static -lwinpthread。从那以后我每次发布前都强制走一遍这个检查清单，再也没收到过“打不开”的反馈。希望帮到你。本文还有配套的精品资源，点击获取
简介：MinGW for Win64 是面向 Windows 64 位平台的 GCC 编译器工具链资源，适合在本地学习 C++、希望摆脱大型 IDE 依赖的开发者与编程初学者。它提供命令行编译环境，可快速完成代码编译与调试，帮助理解从源码到可执行文件的完整过程。压缩包为 zip 格式，整体约 156.05MB，包内以 GCC 编译器、libstdc++ 标准库、Binutils 链接与汇编工具、Make 构建工具及头文件、静态/动态库等开发组件为主，覆盖 C++11、C++14、C++17 标准及部分 C++20 特性。资源中的 TDM-GCC-64 是 MinGW 针对 64 位 Windows 优化的分支，集成较新的 GCC 版本与库，可生成并运行 64 位应用程序。目前已有 115 人学习下载，适合需要轻量级本地编译环境、想体验 GCC 稳定性与标准支持的 C++ 学习者参考使用。1. MinGW for Win64：把 Linux 风格的 C++ 工具链搬到 Windows 上如果你在 Windows 上写 C++，却不想装几个 GB 的 Visual Studio，又希望g++、gdb、make这些命令能像在 Linux 上一样随手就用，那 MinGW for Win64 就是为你准备的。它本质上是把 GCC 工具链裁剪并移植到 Windows 64 位环境，让你在原生 Windows 下编译出.exe，不需要模拟层，也不需要 WSL。我见过太多人卡在“装完不会配环境变量”或者“编译出来缺 DLL”这两步上，其实只要搞清楚它的目录结构和链接模型，十分钟就能跑通第一个程序。这份资源适合三类人：刚学 C++ 不想被 IDE 绑架的新手、需要交叉编译 Windows 目标的老手、以及想用 CMake + GCC 组合做持续集成的开发者。2. 拆开目录看门道：bin、lib、include 各管什么2.1 工具链的四个核心目录拿到 MinGW for Win64 的压缩包，解压后你会看到类似mingw64的根目录。别急着配 PATH，先花两分钟看清楚里面有什么。常见结构是bin、lib、include、libexec四个目录，外加一个share放文档。bin里是可执行文件，包括gcc.exe、g++.exe、gdb.exe、mingw32-make.exe、windres.exe等。lib里是静态库和导入库，比如libstdc++.a、libgcc.a、libwinpthread.a。include是 C 和 C++ 标准库头文件，以及 Windows API 的兼容头文件。libexec里是 GCC 内部调用的子程序，比如cc1plus.exe，你平时不会直接碰它，但缺了它编译就会报“cannot execute cc1plus”。我一般会先确认bin下有没有g++.exe和gcc.exe，再用g++ --version看版本号。如果输出里带x86_64-w64-mingw32字样，说明这是 64 位目标。注意，有些打包版本会把 32 位和 64 位混在一起，bin下同时有gcc.exe和x86_64-w64-mingw32-gcc.exe，后者才是明确针对 Win64 的。如果你直接调gcc，可能默认走 32 位，链接时就会报架构不匹配。2.2 环境变量怎么配才不打架配置 PATH 是最容易翻车的地方。假设你解压到了D:\tools\mingw64，那么需要把D:\tools\mingw64\bin加到系统 PATH 的最前面。为什么强调最前面？因为 Windows 上可能已经装了其他编译器，比如 MSYS2 的 GCC 或者旧版 MinGW，如果它们的路径排在前面，你敲g++调到的就不是这份资源里的版本。我习惯在 PowerShell 里用$env:Path临时验证：# 临时把 MinGW 的 bin 放到 PATH 最前，只对当前会话生效 $env:Path = "D:\tools\mingw64\bin;" + $env:Path # 确认调用的 g++ 路径和版本 where.exe g++ g++ --version第一行把新路径拼到最前面，第二行where.exe会列出所有匹配的g++，排在第一的就是当前生效的。第三行看版本输出，如果显示x86_64-w64-mingw32且版本号符合预期，说明配置正确。永久生效需要去“系统属性 → 环境变量”里编辑 Path，把D:\tools\mingw64\bin上移到最顶。注意不要同时把bin和mingw64根目录都加进去，那样容易让某些脚本找不到相对路径。2.3 第一个编译命令与链接参数环境配好后，写一个最简单的hello.cpp：// hello.cpp #include <iostream> int main() { std::cout << "MinGW for Win64 works!" << std::endl; return 0; }编译命令我一般用：g++ hello.cpp -o hello.exe -static-libgcc -static-libstdc++这里-o hello.exe指定输出文件名，-static-libgcc和-static-libstdc++是关键。默认情况下，MinGW 动态链接libgcc_s_seh-1.dll和libstdc++-6.dll，如果你把hello.exe拷到没装 MinGW 的机器上，就会弹窗报“找不到 libstdc++-6.dll”。加上这两个静态链接选项后，生成的 exe 不依赖这些 DLL，体积会大几十 KB，但换来的是单文件可分发。如果你确实想动态链接，那就得把bin下的对应 DLL 一起拷走，或者用-Wl,-rpath指定相对路径，但在 Windows 上 rpath 支持有限，不如静态链接省心。3. 从单文件到多文件：make 与 CMake 的落地配置3.1 用 mingw32-make 跑通 MakefileMinGW for Win64 自带的是mingw32-make.exe，不是make.exe。你可以手动改名为make.exe，也可以直接用它。写一个三文件的工程：main.cpp、math_utils.cpp、math_utils.h。Makefile 可以这样写：# Makefile for MinGW for Win64 CXX = g++ CXXFLAGS = -std=c++17 -Wall -O2 -static-libgcc -static-libstdc++ TARGET = app.exe OBJS = main.o math_utils.o $(TARGET): $(OBJS) $(CXX) $(OBJS) -o $(TARGET) $(CXXFLAGS) %.o: %.cpp $(CXX) $(CXXFLAGS) -c $< -o $@ clean: del /Q $(OBJS) $(TARGET)注意clean里用的是del /Q，这是 Windows 命令，不是 Linux 的rm -f。如果你在 Git Bash 里跑 make，del会找不到，得改成rm -f。我一般会在 Makefile 开头判断系统，但为了简单，直接写del并在 cmd 或 PowerShell 里执行mingw32-make最稳。CXXFLAGS里的-std=c++17指定标准，-Wall开警告，-O2优化。%.o: %.cpp是模式规则，$<表示依赖文件，$@表示目标文件。执行mingw32-make后，你会看到先编译两个.o，再链接成app.exe。3.2 CMake 生成 MinGW MakefilesCMake 是更现代的选择。假设你有一个CMakeLists.txt：cmake_minimum_required(VERSION 3.15) project(MinGW64Demo CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 强制静态链接 libgcc 和 libstdc++ set(CMAKE_EXE_LINKER_FLAGS "-static-libgcc -static-libstdc++") add_executable(app main.cpp math_utils.cpp)在项目根目录下建一个build文件夹，然后执行：cd build cmake -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE=Release .. mingw32-make-G "MinGW Makefiles"告诉 CMake 生成给mingw32-make用的构建文件。如果你不加这个参数，CMake 可能默认找 Visual Studio 生成器，结果报错说找不到cl.exe。-DCMAKE_BUILD_TYPE=Release会启用-O3 -DNDEBUG。CMAKE_EXE_LINKER_FLAGS里加静态链接选项，保证生成的 exe 不依赖 MinGW 的 DLL。执行完mingw32-make后，build目录下会出现app.exe。我习惯在CMakeLists.txt里再加一句set(CMAKE_RUNTIME_OUTPUT_DIRECTORY ${CMAKE_BINARY_DIR}/bin)，把 exe 统一放到bin下，方便打包。3.3 调试信息与 gdb 的配合编译时加-g才能用 gdb 调试。比如：g++ -g -O0 main.cpp math_utils.cpp -o app_debug.exe gdb app_debug.exe进入 gdb 后，break main设断点，run启动，next单步，print 变量名看值。MinGW for Win64 自带的 gdb 通常支持 Python 脚本，但如果你遇到During startup program exited with code 0xc0000135，多半是缺 DLL。因为 gdb 本身也依赖libstdc++-6.dll等，如果你把bin从 PATH 里移除了，gdb 就起不来。所以调试时确保 PATH 里有 MinGW 的bin。另外，-O0关闭优化，否则断点可能跳来跳去，变量被优化掉，这就是所谓的“玄学调试”。4. 避坑与排查：五个让你少熬两晚的踩坑记录4.1 现象：编译报 “undefined reference to__imp_WinMain@16”原因：链接器找不到入口点。常见于你写了int main()但编译时用了-mwindows，或者反过来，你写了WinMain却按控制台程序链接。MinGW for Win64 默认入口是mainCRTStartup，对应main。如果你在 CMake 里加了WIN32关键字，CMake 会传-mwindows，此时需要WinMain。解决：控制台程序不要加-mwindows，GUI 程序确保函数签名是int WINAPI WinMain(HINSTANCE, HINSTANCE, LPSTR, int)。检查 CMake 的add_executable(app WIN32 ...)是否误加。4.2 现象：exe 在别的电脑上弹窗“找不到 libstdc++-6.dll”原因：动态链接了 GCC 运行时库，目标机器没装 MinGW。解决：编译时加-static-libgcc -static-libstdc++，或者用-static全静态链接。注意-static可能导致某些 Windows API 库冲突，一般只加前两个就够。如果还缺libwinpthread-1.dll，再加-static -lpthread或-Wl,-Bstatic -lwinpthread -Wl,-Bdynamic。4.3 现象：mingw32-make报 “make: *** No rule to make target 'xxx.o'”原因：Makefile 里的模式规则没匹配上，或者源文件扩展名不是.cpp。常见于你把文件存成了.c但用g++编译，或者路径里有空格。解决：确认源文件后缀与规则一致。路径有空格时，用引号包起来，或者在 Makefile 里用$(wildcard *.cpp)自动收集。我一般把项目放在没有空格的路径下，比如D:\work\demo。4.4 现象：gdb 启动报 “During startup program exited with code 0xc0000135”原因：gdb 依赖的 DLL 不在 PATH 里，或者你编译的 exe 依赖的 DLL 缺失。解决：把D:\tools\mingw64\bin加到 PATH 最前，重新开一个终端。用where.exe libstdc++-6.dll确认能找到。如果还不行，用ldd app.exe（MinGW 自带ldd.exe）看缺哪个 DLL，手动拷到 exe 同目录。4.5 现象：CMake 配置时报 “CMAKE_CXX_COMPILER not set”原因：CMake 没找到g++，或者你用了-G "Visual Studio"但没装 VS。解决：在build目录下先cmake -G "MinGW Makefiles" ..，并确保g++在 PATH 里。如果之前配置过其他生成器，删掉build下的CMakeCache.txt再重来。我习惯每次换生成器都清空build目录，避免缓存干扰。5. 进阶技巧：用 windres 加图标与版本信息5.1 准备 .rc 文件与图标MinGW for Win64 自带windres.exe，可以把 Windows 资源编译进 exe。新建app.rc：#include <windows.h> IDI_ICON1 ICON "app.ico" VS_VERSION_INFO VERSIONINFO FILEVERSION 1,0,0,0 PRODUCTVERSION 1,0,0,0 FILEFLAGSMASK 0x3fL FILEFLAGS 0x0L FILEOS 0x40004L FILETYPE 0x1L FILESUBTYPE 0x0L BEGIN BLOCK "StringFileInfo" BEGIN BLOCK "040904b0" BEGIN VALUE "FileDescription", "MinGW64 Demo" VALUE "FileVersion", "1.0.0.0" VALUE "ProductName", "Demo App" END END BLOCK "VarFileInfo" BEGIN VALUE "Translation", 0x409, 1200 END ENDIDI_ICON1 ICON "app.ico"指定图标文件，VERSIONINFO块定义版本信息。040904b0表示英语美国、Unicode。Translation里的0x409是语言 ID，1200是代码页。5.2 编译资源并链接先用windres编译.rc为.o：windres app.rc -O coff -o app_res.o-O coff指定输出 COFF 格式，这是 MinGW 链接器能识别的。然后链接时把app_res.o加进去：g++ main.cpp math_utils.cpp app_res.o -o app.exe -static-libgcc -static-libstdc++如果你用 CMake，可以这样写：set(RES_FILES app.rc) add_executable(app main.cpp math_utils.cpp ${RES_FILES})CMake 会自动调用windres处理.rc文件。生成的app.exe在资源管理器里会显示你设置的图标，右键属性也能看到版本信息。这个技巧在交付给客户时特别有用，不然一个默认的空白图标显得很敷衍。5.3 验证与分发检查清单编译完成后，我习惯做三件事：第一，用objdump -p app.exe | findstr "DLL Name"看依赖了哪些 DLL，确保没有libstdc++-6.dll和libgcc_s_seh-1.dll。第二，把 exe 拷到一个干净的虚拟机或另一台没装 MinGW 的电脑上双击运行。第三，用sigcheck或 PowerShell 的Get-Item app.exe | Select-Object VersionInfo看版本信息是否写入成功。如果依赖列表里还有libwinpthread-1.dll，就在链接时加-static -lwinpthread。从那以后我每次发布前都强制走一遍这个检查清单，再也没收到过“打不开”的反馈。希望帮到你。本文还有配套的精品资源，点击获取