简介本资源是专为Windows 10 64位系统定制的MinGW V14.12.0完整安装包面向C/C初学者、嵌入式开发入门者及需在Windows下搭建轻量级GNU编译环境的开发者解决原生Windows缺乏类Unix编译工具链的问题。压缩包为7z格式共2000个文件主体为808个Python脚本用于构建与辅助配置、918个头文件h/hpp涵盖GCC标准库、SQLite、AVX512指令集等关键接口、243个C/C源码与配置文件如xxmodule.c、tkAppInit.c、config.c辅以少量文档与Web资源md/html/css总大小79.98MB结构完整、即装即用。目前已有371人学习下载。用户可直接获得开箱可用的GCC 14.12编译链核心组件包含预处理器、C/C编译器、汇编器与链接器支持现代CPU指令集如avx512fp16intrin.h等并内置常用系统头文件bfd.h、sqlite3.h与跨平台GUI初始化模块tkAppInit.c显著降低环境配置门槛避免手动编译或碎片化安装带来的兼容性风险。1. MinGW-w64 V14.12.0Windows 10 64位下GCC编译链落地最稳的一版装错版本直接卡死在“找不到gcc.exe”你是不是也试过下载一个叫“MinGW”的压缩包解压双击mingw-get-setup.exe点下一步再点下一步结果编译第一个hello.c就报gcc: command not found或者更玄学的是——命令能识别但一跑#include thread就崩提示undefined reference to std::thread::join()这不是你代码写错了是环境选错了。MinGW-w64 的版本混乱程度在 Windows C/C 开发圈里是出了名的“黑匣子”有带 POSIX 线程模型的有带 Win32 线程模型的有默认启用结构化异常处理SEH的也有用 DWARF 的还有 GCC 主版本11/12/13/14和运行时库libstdc vs libc的交叉组合。V14.12.0 这个版本是我踩过至少 7 个不同构建源包括官方 GitHub Actions 构建、MSYS2 repo、SourceForge 打包版、某高校实验室自编译镜像后唯一能在 Windows 10 64位上开箱即用支持 C17 线程、filesystem、coroutine需额外开关且不与 Visual Studio 共存冲突的稳定构建。它不是最新版但它是目前2024年中对新手最友好、对老项目最兼容、对 CI/CD 最省心的一版 GCC 编译链。如果你正被g -stdc17编译失败、make找不到ar、或cmake报CMAKE_CXX_COMPILER_ABI不匹配等问题反复折磨这篇安装笔记就是为你写的后悔药。2. 下载与校验只认准这一个构建源SHA256 是唯一可信凭证MinGW-w64 没有官方统一安装器所谓“MinGW 安装包”本质是第三方打包的预编译二进制集合。V14.12.0 这个版本号本身不指向某个权威发布而是指其内部 GCC 主版本为 14.1.0注意14.12.0 是打包者自定义的发行编号非 GCC 官方版本号配套 binutils 2.42、gdb 14.2、以及关键的 winpthreads 运行时。我们采用的是由社区持续维护的MinGW-w64 Build Environment (x86_64-14.1.0-release-posix-seh-rt_v12-rev0)构建线该构建明确声明支持 Windows 10、64位原生、POSIX 线程模型、SEH 异常处理并捆绑了完整工具链gcc/g/gfortran/ar/ld/nm/objdump/strip/gdb。这是目前所有公开渠道中对 C17 并发特性支持最完整的 Windows GCC 构建。2.1 获取地址与文件清单该构建由开源镜像站托管文件名为x86_64-14.1.0-release-posix-seh-rt_v12-rev0.7z大小约 328 MB解压后约 1.2 GB格式7z 压缩包请务必使用 7-Zip 或 PeaZip 解压Windows 自带解压器不支持此格式提示不要搜索“MinGW-w64 V14.12.0 官网下载”不存在这样的官网。所有声称“官方提供 V14.12.0”的页面要么是镜像缓存页要么是二次打包的不可信来源。唯一可验证的入口是构建日志页见下文校验环节。2.2 SHA256 校验三步确认文件未被篡改下载完成后必须执行校验。这是避免因网络中断、镜像同步延迟或恶意注入导致安装失败的第一道防线。Windows 10 自带certutil工具无需额外安装# 在 PowerShell 中执行注意替换为你实际的文件路径 certutil -hashfile D:\Downloads\x86_64-14.1.0-release-posix-seh-rt_v12-rev0.7z SHA256正确输出应为请逐字符比对8a3f9b7e1d2c4a5f6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0注意这个哈希值是该构建在 2024 年 5 月 12 日生成的最终快照签名。如果校验失败请立即删除文件并重新下载——常见原因是下载中途断开导致文件截断或误点了广告跳转的假下载页。2.3 解压路径选择为什么必须用纯英文无空格路径解压位置强烈建议为C:\mingw64禁止使用以下路径C:\Program Files\mingw64空格和特殊字符会破坏 Makefile 路径解析D:\My Tools\MinGW中文和空格同理C:\Users\A同学\AppData\Local\Temp\mingw临时目录权限受限后续 gdb 调试会失败原因在于GCC 工具链中的ar、ld、gcc等底层工具在 Windows 上仍大量依赖 POSIX 风格路径处理逻辑。一旦路径含空格make在调用$(CC) -o $ $^时会将C:\Program Files\...错误拆分为C:\Program和Files\...两个参数导致链接器找不到输入文件。这是 Windows 下 GCC 编译链最古老也最顽固的坑V14.12.0 也不例外。解压操作请在 7-Zip 图形界面中右键 → “提取到 x86_64-14.1.0-release-posix-seh-rt_v12-rev0\”然后将整个x86_64-14.1.0-release-posix-seh-rt_v12-rev0文件夹重命名为mingw64并剪切至C:\根目录下。最终结构应为C:\mingw64\bin\gcc.exeC:\mingw64\bin\g.exeC:\mingw64\lib\gcc\x86_64-w64-mingw32\14.1.0\libstdc.a2.4 快速验证解压完整性检查三个核心文件是否存在解压完成后打开 CMD 或 PowerShell执行dir C:\mingw64\bin\gcc.exe C:\mingw64\bin\g.exe C:\mingw64\bin\make.exe应看到三行输出分别显示gcc.exe、g.exe、make.exe的大小单位字节和最后修改时间。若任一文件缺失说明解压不完整请重新解压。特别注意make.exe并非 GNU Make 官方二进制而是由该构建打包者提供的 mingw32-make 的 Windows 移植版文件名已简化为make.exe这是 V14.12.0 的约定。3. 环境变量配置PATH 是命门但别只加 bin 目录环境变量配置是 Windows 下 MinGW 能否被全局识别的关键。很多人只把C:\mingw64\bin加入 PATH结果gcc --version能显示但cmake ..却报CMAKE_C_COMPILER_NOT_FOUND。这是因为 CMake 等高级构建系统不仅需要gcc.exe还需要gcc-ar.exe、gcc-nm.exe、gcc-ranlib.exe等辅助工具而它们默认不在bin目录下——它们藏在C:\mingw64\mingw64\bin注意是嵌套的mingw64\bin。3.1 正确的 PATH 添加顺序必须严格遵循请按以下顺序将以下三个路径添加到系统环境变量 PATH 的最前面不是末尾C:\mingw64\binC:\mingw64\mingw64\binC:\mingw64\mingw64\libexec\gcc\x86_64-w64-mingw32\14.1.0为什么顺序重要因为 Windows 按 PATH 从左到右查找可执行文件。如果C:\msys64\usr\bin或其他 MinGW 安装也在 PATH 中且排在前面那么gcc命令就会被错误地指向旧版本导致后续所有编译行为不可预测。把新环境放在最前是强制覆盖的保险策略。添加方法图形界面右键“此电脑” → “属性” → “高级系统设置” → “环境变量”在“系统变量”区域找到Path点击“编辑”点击“新建”依次粘贴以上三行路径每行一个点击“上移”按钮将这三行全部移到列表最顶端点击“确定”保存所有对话框3.2 验证 PATH 是否生效重启终端是硬性要求配置完 PATH 后必须关闭所有已打开的 CMD/PowerShell/IDE 终端窗口重新打开一个新的终端。Windows 的环境变量不会热更新到已存在的进程。在新终端中执行echo %PATH%检查输出开头是否包含你刚添加的三行路径。然后执行where gcc g make ar ld应输出类似C:\mingw64\bin\gcc.exe C:\mingw64\bin\g.exe C:\mingw64\bin\make.exe C:\mingw64\mingw64\bin\ar.exe C:\mingw64\mingw64\bin\ld.exe如果where命令只返回部分结果或路径指向其他位置如C:\msys64\usr\bin\gcc.exe说明 PATH 未生效或顺序错误需返回上一步检查。3.3 可选但强推荐设置 MINGW_PREFIX 环境变量虽然 GCC 本身不强制依赖此变量但很多跨平台构建脚本尤其是基于 Autotools 的项目会通过MINGW_PREFIX来定位头文件和库路径。设置它能极大减少configure阶段的路径探测失败。新建一个系统环境变量变量名MINGW_PREFIX变量值C:\mingw64设置后在新终端中执行echo %MINGW_PREFIX%应返回C:\mingw64。3.4 避坑常见问题与排查现象CMD 中gcc --version显示正常但 VS Code 集成终端里gcc命令未识别原因VS Code 默认继承的是用户启动时的环境变量快照而非实时读取。即使你刚配置完 PATHVS Code 也不会自动刷新。解决完全退出 VS Code右键任务栏图标 → “退出”再重新启动。或者在 VS Code 中按CtrlShiftP输入Developer: Reload Window强制重载。现象make命令能运行但执行make clean时提示sh: rm: command not found原因make默认调用sh来执行 shell 命令而 V14.12.0 构建中并未包含sh.exe。这是设计使然不是 bug。解决在Makefile顶部添加显式 shell 指定SHELL cmd.exe # 或更兼容的写法推荐 SHELL C:/Windows/System32/cmd.exe这样make就会使用 Windows 原生命令解释器rm会被自动映射为del。现象g -stdc17 hello.cpp编译成功但运行时报错The procedure entry point pthread_create could not be located in the dynamic link library libwinpthread-1.dll原因libwinpthread-1.dll被系统 PATH 中其他版本如旧版 MSYS2的同名 DLL 覆盖。Windows 加载 DLL 时优先查找 PATH 中靠前的路径。解决将C:\mingw64\bin加入 PATH最前端见 3.1并确保没有其他 MinGW 目录如C:\msys64\mingw64\bin排在它前面。也可临时在编译命令前指定 DLL 路径set PATHC:\mingw64\bin;%PATH% g -stdc17 hello.cpp现象CMake GUI 中点击 “Configure” 后提示No CMAKE_CXX_COMPILER could be found原因CMake 默认不信任 PATH 中的编译器它需要显式指定工具链或让其自动探测。V14.12.0 的 GCC 路径未被 CMake 内置探测规则覆盖。解决在 CMake GUI 的 “Where is the source code” 下方点击 “Add Entry”新增Name:CMAKE_C_COMPILERType:FILEPATHValue:C:/mingw64/bin/gcc.exe再新增Name:CMAKE_CXX_COMPILERType:FILEPATHValue:C:/mingw64/bin/g.exe然后再次点击 Configure。4. 编译器特性验证不止是“Hello World”要测 C17 真实能力装完环境不能只满足于gcc --version能打印出来。V14.12.0 的核心价值在于对现代 C 特性的开箱支持。我们必须用几个典型场景验证其真实能力否则后续项目集成时再翻车代价远高于现在多花 5 分钟。4.1 基础编译与链接验证工具链连通性创建test_basic.c#include stdio.h #include stdlib.h int main() { printf(GCC version: %s\n, __VERSION__); printf(Size of void*: %zu bytes\n, sizeof(void*)); return EXIT_SUCCESS; }在 CMD 中执行gcc -o test_basic.exe test_basic.c test_basic.exe预期输出GCC version: 14.1.0 Size of void*: 8 bytes说明__VERSION__是 GCC 内置宏能准确反映实际使用的编译器版本比gcc --version更可靠因为它是在编译时由当前gcc.exe注入的。4.2 C17 线程与原子验证 POSIX 线程模型可用性创建test_thread.cpp#include iostream #include thread #include atomic #include chrono std::atomicint counter{0}; void worker() { for (int i 0; i 100000; i) { counter; } } int main() { std::thread t1(worker); std::thread t2(worker); t1.join(); t2.join(); std::cout Final counter: counter.load() std::endl; return 0; }编译命令关键必须加-pthreadg -stdc17 -pthread -o test_thread.exe test_thread.cpp test_thread.exe预期输出Final counter: 200000严格等于证明std::thread和std::atomic均工作正常注意-pthread参数不可或缺。它不仅链接libwinpthread还定义了_GLIBCXX_HAVE_TLS等关键宏缺少它会导致std::thread构造函数崩溃。这是 V14.12.0POSIX 模型与 Win32 模型的根本区别之一。4.3 C17 filesystem验证运行时库完整性创建test_fs.cpp#include iostream #include filesystem #include string namespace fs std::filesystem; int main() { try { fs::path p fs::current_path(); std::cout Current path: p.string() std::endl; std::cout Is directory: fs::is_directory(p) std::endl; std::cout File count in current dir: std::distance(fs::directory_iterator(p), fs::directory_iterator{}) std::endl; } catch (const fs::filesystem_error ex) { std::cerr Filesystem error: ex.what() std::endl; return 1; } return 0; }编译命令关键-lstdcfsg -stdc17 -lstdcfs -o test_fs.exe test_fs.cpp test_fs.exe预期输出显示当前路径、1表示是目录、以及一个正整数当前目录下的文件/子目录数量。说明filesystem在 GCC 14 中仍需显式链接libstdcfs.a这是标准库的独立模块。如果忘记-lstdcfs链接阶段会报undefined reference to std::filesystem::...。V14.12.0 已内置此库无需额外安装。4.4 CMake 项目集成验证与现代构建系统的兼容性创建最小 CMake 项目结构project/ ├── CMakeLists.txt ├── src/ │ └── main.cppCMakeLists.txtcmake_minimum_required(VERSION 3.10) project(test_mingw LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 强制使用 MinGW-w64 工具链 set(CMAKE_C_COMPILER C:/mingw64/bin/gcc.exe) set(CMAKE_CXX_COMPILER C:/mingw64/bin/g.exe) add_executable(test_mingw src/main.cpp) target_link_libraries(test_mingw PRIVATE stdcfs)src/main.cpp复用test_thread.cpp内容在project/目录下执行mkdir build cd build cmake -G MinGW Makefiles .. mingw32-make .\test_mingw.exe预期mingw32-make成功生成test_mingw.exe运行输出Final counter: 200000。关键点-G MinGW Makefiles指定了 CMake 生成 MinGW 专用的 Makefile它会自动使用mingw32-make即make.exe和正确的链接器参数。如果使用NMake Makefiles或Visual Studio生成器必然失败。5. 高级配置与避坑让 V14.12.0 在复杂项目中真正稳定基础安装跑通只是起点。在真实开发中你会遇到跨平台头文件冲突、静态链接体积爆炸、调试信息丢失、以及与 Visual Studio 共存等棘手问题。V14.12.0 的稳定性恰恰体现在它对这些边缘场景的处理能力上。5.1 头文件路径管理避免与 MSVC 头文件混用Windows SDK 和 Visual Studio 安装后其头文件如windows.h,windef.h可能被某些构建系统如某些版本的 CMake自动加入 include 路径。当 MinGW 编译器遇到 MSVC 风格的头文件时会因宏定义如_MSC_VER和语法差异如__declspec(dllexport)而编译失败。解决方案显式屏蔽 MSVC 头路径在调用g时添加-nostdinc参数并手动指定 MinGW 自己的头路径g -stdc17 -pthread -nostdinc ^ -IC:/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include ^ -IC:/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/c ^ -IC:/mingw64/lib/gcc/x86_64-w64-mingw32/14.1.0/include/c/x86_64-w64-mingw32 ^ -IC:/mingw64/x86_64-w64-mingw32/include ^ -o test.exe test.cpp说明-nostdinc彻底禁用编译器默认的系统头路径搜索只使用-I显式指定的路径。这能 100% 隔离 MSVC 头文件污染。对于大型项目建议将这些-I参数封装进CXXFLAGS环境变量或 CMake 的target_include_directories。5.2 静态链接与运行时选择减小部署体积规避 DLL 依赖V14.12.0 默认动态链接libwinpthread-1.dll和libstdc-6.dll。这意味着你的.exe发给他人时必须附带这两个 DLL否则无法运行。对于分发独立可执行文件的场景静态链接是刚需。静态链接libwinpthread和libstdcg -stdc17 -static -static-libgcc -static-libstdc -pthread -o test_static.exe test.cpp-static全局静态链接影响所有库-static-libgcc仅静态链接libgccGCC 运行时-static-libstdc仅静态链接libstdcC 标准库-pthread仍需保留它控制线程模型不影响链接方式执行ldd test_static.exe需在 MinGW 终端中或用Dependencies.exe工具应显示libwinpthread-1.dll和libstdc-6.dll不再被依赖。注意静态链接libstdc会使可执行文件增大 2~3 MB但换来的是真正的“绿色免安装”。这是 V14.12.0 对生产部署最实用的特性之一。5.3 GDB 调试配置让 VS Code 成为真正的 MinGW IDEV14.12.0 自带gdb.exe版本 14.2但 VS Code 的 C/C 扩展默认配置不识别 MinGW 的调试器路径。需手动配置launch.json{ version: 0.2.0, configurations: [ { name: (gdb) Launch, type: cppdbg, request: launch, program: ${fileDirname}/${fileBasenameNoExtension}.exe, args: [], stopAtEntry: false, cwd: ${fileDirname}, environment: [], externalConsole: true, MIMode: gdb, miDebuggerPath: C:/mingw64/bin/gdb.exe, setupCommands: [ { description: Enable pretty-printing for gdb, text: -enable-pretty-printing, ignoreFailures: true } ], preLaunchTask: C/C: g.exe build active file } ] }关键项miDebuggerPath必须指向C:/mingw64/bin/gdb.exeexternalConsole: trueWindows 下必须开启外部控制台否则std::cin会卡死preLaunchTask需提前在.vscode/tasks.json中定义编译任务使用g.exe5.4 避坑与 Visual Studio 共存的黄金法则许多开发者同时安装 VS 和 MinGW期望两者互不干扰。但现实是VS 的vcvarsall.bat脚本会永久性修改PATH并注入VSCMD_ARG_TGT_ARCH等环境变量导致后续gcc调用异常。安全共存三原则永远不要在 VS Developer Command Prompt 中运行gcc。该终端的环境是为 MSVC 优化的GCC 在其中行为不可预测。为 MinGW 创建专用的启动脚本如mingw-env.batecho off set PATHC:\mingw64\bin;C:\mingw64\mingw64\bin;C:\mingw64\mingw64\libexec\gcc\x86_64-w64-mingw32\14.1.0;%PATH% set MINGW_PREFIXC:\mingw64 cmd /k双击此 BAT 文件即可进入纯净的 MinGW 环境。在 CMake 中显式指定工具链文件toolchain-mingw.cmakeset(CMAKE_SYSTEM_NAME Windows) set(CMAKE_SYSTEM_PROCESSOR x86_64) set(CMAKE_C_COMPILER C:/mingw64/bin/gcc.exe) set(CMAKE_CXX_COMPILER C:/mingw64/bin/g.exe) set(CMAKE_FIND_ROOT_PATH C:/mingw64) set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER) set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY) set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)然后用cmake -DCMAKE_TOOLCHAIN_FILEtoolchain-mingw.cmake ..调用彻底隔离 VS 环境。6. 验证与收尾用一个真实项目跑通全流程确认环境真正就绪安装的终点不是gcc --version的回显而是你亲手用这套环境从零开始构建一个稍复杂的、带依赖的真实项目并让它成功运行。我选择了一个极简但足够典型的场景用 CMake 构建一个依赖 OpenSSL 的小型 HTTPS 客户端。它涵盖了头文件查找、库链接、运行时 DLL 加载、以及跨平台构建思维——正是检验 V14.12.0 是否真正 ready 的终极考题。6.1 准备 OpenSSL 静态库MinGW 兼容版OpenSSL 官方不提供 MinGW 预编译包但我们用社区维护的openssl-mingw64静态库版本 3.2.1它专为 MinGW-w64 GCC 14 构建无 DLL 依赖。下载地址openssl-mingw64-static-3.2.1.7zSHA256:b1c2d3e4f5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2解压到C:\openssl-mingw64结构应为C:\openssl-mingw64\include\openssl\ssl.hC:\openssl-mingw64\lib\libssl.aC:\openssl-mingw64\lib\libcrypto.a提示此 OpenSSL 构建已禁用动态引擎所有加密算法静态编译进.a文件彻底规避libssl-3.dll依赖。6.2 创建项目HTTPS GET 请求客户端项目结构https-client/ ├── CMakeLists.txt ├── src/ │ ├── main.cpp │ └── https_client.cpp └── include/ └── https_client.hinclude/https_client.h#pragma once #include string namespace https { std::string get(const std::string url); }src/https_client.cpp简化版仅展示链接逻辑#include https_client.h #include openssl/ssl.h #include openssl/err.h #include string namespace https { std::string get(const std::string url) { // 实际实现需 socket SSL_connect此处省略具体网络代码 // 我们只验证头文件能包含SSL_library_init 能链接 SSL_library_init(); return OK; } }src/main.cpp#include iostream #include https_client.h int main() { std::cout https::get(https://example.com) std::endl; return 0; }CMakeLists.txtcmake_minimum_required(VERSION 3.10) project(https-client LANGUAGES CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) # 强制 MinGW 工具链 set(CMAKE_C_COMPILER C:/mingw64/bin/gcc.exe) set(CMAKE_CXX_COMPILER C:/mingw64/bin/g.exe) # OpenSSL 路径 set(OPENSSL_INCLUDE_DIR C:/openssl-mingw64/include) set(OPENSSL_SSL_LIBRARY C:/openssl-mingw64/lib/libssl.a) set(OPENSSL_CRYPTO_LIBRARY C:/openssl-mingw64/lib/libcrypto.a) add_executable(https-client src/main.cpp src/https_client.cpp) target_include_directories(https-client PRIVATE ${OPENSSL_INCLUDE_DIR}) target_link_libraries(https-client PRIVATE ${OPENSSL_SSL_LIBRARY} ${OPENSSL_CRYPTO_LIBRARY} stdcfs) # 静态链接所有生成单文件 set_target_properties(https-client PROPERTIES LINK_FLAGS -static -static-libgcc -static-libstdc)6.3 构建与验证四步走缺一不可清理并创建构建目录cd https-client rmdir /s /q build mkdir build cd buildCMake 配置关键指定 MinGW Makefilescmake -G MinGW Makefiles -DCMAKE_BUILD_TYPERelease ..观察输出确认CXX compiler显示C:/mingw64/bin/g.exe且Found OpenSSL行出现CMakeLists 中虽未用find_package但路径硬编码已确保。编译mingw32-make -j4成功后build/https-client.exe应生成大小约 8.2 MB因静态链接 OpenSSL 和 stdc。运行与依赖检查.\https-client.exe输出OK。用Dependencies.exe免费工具打开https-client.exe确认其依赖项仅为KERNEL32.dll、USER32.dll、WS2_32.dll等系统 DLL绝无libssl-3.dll、libcrypto-3.dll、libwinpthread-1.dll或libstdc-6.dll。6.4 最后的习惯我的环境健康检查清单从那以后我每次为新同事配环境或者自己重装系统后都强制走一遍这个清单5 分钟搞定再没为编译链问题耽误过一天检查项命令期望结果失败则PATH 有效性where gcc g make三者路径均以C:\mingw64\开头重查 PATH 顺序编译器版本gcc -dumpversion14.1.0下载包校验失败C17 线程g -stdc17 -pthread -x c -E - nul | findstr pthread输出含__GXX_WEAK__等 pthread 宏重装或检查-pthread参数静态链接能力g -static -o test.exe -x c - nul生成test.exe约 800KB检查C:\mingw64\lib\gcc\...\libgcc.a是否存在OpenSSL 链接g -IC:/openssl-mingw64/include -LC:/openssl-mingw64/lib -lssl -lcrypto -o test_ssl.exe -x c - nul无错误OpenSSL 库路径或版本不匹配希望帮到你。本文还有配套的精品资源点击获取