MinGW64编译OpenCV 4.10完整指南：从环境配置到CMake项目集成

简介这是基于MinGW-w64 14.2.0工具链预编译的OpenCV 4.10开发包面向Windows C开发者主要解决在Windows下自行编译OpenCV时面临的CMake配置、GCC依赖和链接参数繁杂等问题OpenCV官方预编译版本通常针对MSVCMinGW用户往往需要从源码构建该压缩包直接提供对应工具链的编译结果省去安装额外依赖和反复调整构建参数的环节。编译环境采用win10、CMake 3.30.3与UCRT运行时兼容POSIX标准并支持SEH结构化异常处理由此得到的库文件可较好地与Windows原生API协同工作。压缩包共442个文件总大小约30.56MB包含297个hpp头文件、56个h头文件、16个DLL动态库、15个a导入库/静态库以及XML分类模型、CMake配置文件、OpenEXR与libtiff等第三方许可证和说明文档。头文件用于接口声明DLL与.a库供程序运行时和链接期使用XML文件可用于加载OpenCV自带的级联分类模型整体目录结构清晰能直接放入MinGW项目引用。已有929人学习下载适合需要快速集成OpenCV视觉功能的C项目开发者。1. 用 MinGW64 编译 OpenCV 4.10为什么没人直接给你传编译结果用 MinGW64 编译 OpenCV 4.10听起来只是把源码跑一遍 CMake实际做起来却会让不少人卡在配置阶段。我最早是在 CLion 里做 OpenCV 图像处理项目发现官方预编译包只匹配 MSVC 运行库g 去链接时满屏 LNK 错误换成 .dll.a 也不对。后来想通了OpenCV 4.10 的二进制必须和你的工具链同属一套 ABIMinGW64 和 MSVC 天生不通用。这条路的真正价值是让你在 Windows 上彻底摆脱 Visual Studio 工程CLion、Qt、独立 CMake 工程都能用同一套 OpenCV 4.10。适合要做 C 图像处理、还想自己控制模块开关的人。2. 编译前的环境底子MinGW64、CMake 和依赖库先别打架在动手编译 OpenCV 4.10 之前先承认一个事实Windows 上 DLL 和静态库都绑着工具链的 ABI。MSVC 编译的opencv_world410.lib用的是 MSVC 的名字修饰规则和 C 运行库MinGW64 的 g 无法直接链接。你如果非要试最后会得到一堆undefined reference或者启动时崩溃。与其去猜别人给的二进制能不能用不如把环境拆开看明白。2.1 分清 MinGW64 和 MSYS2你用的是编译器还是 Linux 模拟层很多教程把 MinGW64、MSYS2、MinGW-w64 混着说结果 PATH 里全是坑。MinGW64 说的是 x86_64-w64-mingw32 这套原生 Windows 编译工具链里面真正干活的是 gcc、g、gfortranMSYS2 是一个包管理环境它给你提供/mingw64/bin下的工具同时还带了一个模拟 POSIX 的/usr/bin。如果你在 MSYS2 的 shell 里随手gcc很可能调到的不是 Windows 原生编译器。我一般会在 Windows 的 CMD 里先跑三条命令where gcc where cmake where ninja输出里应该先出现C:\mingw64\bin\gcc.exe然后是C:\cmake\bin\cmake.exe这类路径。如果第一条输出指向 Git 自带的C:\Program Files\Git\usr\bin\gcc.exe后面 CMake 对 OpenCV 4.10 做编译器测试时一定会翻车。Git Bash 里的 gcc 不是 MinGW64 的 Windows 发行版它连 PE 可执行文件都未必生成正确。再看编译器自身的目标平台gcc -dumpmachine看到x86_64-w64-mingw32就是对的。看到i686-w64-mingw32说明你装的是 32 位工具链编 OpenCV 4.10 也能编但输出库只能给 32 位程序用看到msys或者带其他字样的请先重装工具链。2.2 按 mingw64 安装教程做环境检查三条命令能看穿大部分问题如果你用 MSYS2 来维护工具链最省心的是打开 MINGW64 终端同步软件源后安装整套核心包pacman -Syu pacman -S --needed mingw-w64-x86_64-gcc \ mingw-w64-x86_64-cmake \ mingw-w64-x86_64-ninja \ mingw-w64-x86_64-make注意包名里的前缀必须是mingw-w64-x86_64-。这个前缀决定装进/mingw64/bin由 MSYS2 的 MINGW64 终端使用。如果误装了不带前缀的gcc那是 MSYS2 自己用的编译器目标平台是 MSYS不是 MinGW64OpenCV 4.10 的 CMake 配置会非常难看。用 standalone 工具链也一样解压后把bin目录放到 PATH 最前面。还有一条血泪经验工具链路径里不要有空格。OpenCV 的 CMake 脚本在找编译器、生成导入库时会对路径做各种字符串拼接路径带空格的结果就是找不到文件而且错误信息指向的文件明明存在。我在C:\Program Files\mingw64下吃过一次亏后来统一放到C:\mingw64再没犯过。2.3 OpenCV 4.10 的依赖该怎么选全套打开和最小构建是两条路OpenCV 4.10 是模块化构建核心模块是 core、imgproc、imgcodecs、videoio、highgui剩下的很多是可选模块。第一次用 MinGW64 编译我不建议一上来就开满。依赖或模块作用配置变量首次建议IPPIntel 图像原语加速WITH_IPPOFF省去下载 ippicvTBBparallel_for 多线程后端WITH_TBBOFF没装 TBB 就开只会报错FFmpeg视频文件读写WITH_FFMPEG先 OFF跑通基础再开Qtimshow 的窗口后端WITH_QTOFF等接 Qt 工程时再开OpenGL3D 显示相关WITH_OPENGLOFF还有一点容易被忽略CMake 配置阶段会在源码目录下的.cache里下载第三方包。只要WITH_IPPOFFippicv 这个大头就不会被拉下来如果默认开着等它下载会让人以为电脑卡死了。这个.cache目录不是源码配置失败后不要整个删源码删掉.cache再重新配置就够了。常见做法是先编译一套只有基础模块的最小版本把整个链路验证通再根据需要追加模块。像张量运算、solvePnP、DCT 盲水印、骨架提取这些功能很多只依赖 core 和 imgproc最小版本完全覆盖。3. OpenCV 4.10 的 cmake 编译步骤第一版配置命令和关键参数CMake 配置 OpenCV 4.10 是所有步骤里最值得认真写的。它不会像 pip 安装那样自己决定一切也不会像 Visual Studio 向导那样帮你隐藏工具链细节。这一步写清楚后面编出来的库你能一直用。3.1 一条能跑通的 CMake 命令从源码到 build 目录我推荐把源码目录和构建目录分开源码不动构建目录可以随便删。第一次配置不需要把扩展模块拖进来先把 OpenCV 4.10 根源码准备好然后执行cmake -S opencv-4.10 -B build-mingw64 -G MinGW Makefiles \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIXC:/opencv-4.10-mingw64 \ -DBUILD_SHARED_LIBSON \ -DBUILD_opencv_worldON \ -DBUILD_TESTSOFF \ -DBUILD_PERF_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DWITH_IPPOFF \ -DWITH_TBBOFF \ -DWITH_FFMPEGOFF \ -DOPENCV_ENABLE_NONFREEON逻辑上说-S指向 OpenCV 4.10 源码根目录-B指定构建目录-G MinGW Makefiles是让 CMake 用 MinGW 的 make 工具去驱动编译而不是默认的 Visual Studio 生成器。CMAKE_INSTALL_PREFIX决定最后 install 到哪个目录我用正斜杠的C:/opencv-4.10-mingw64避免反斜杠转义问题。这里的开关组合刻意把WITH_FFMPEGOFF因为视频读写的依赖链最长。如果第一次就把 FFmpeg 打开CMake 找不到头文件会报错你分不清是 MinGW64 的问题还是 FFmpeg 的问题。等基础库编完再把视频支持加进去报错面就小很多。3.2 高频开关怎么设图片编码、FFmpeg、TBB、world 模块OpenCV 4.10 的 CMake 开关很多真正影响后面使用的就几个开关取值影响BUILD_SHARED_LIBSON生成 DLL运行期可更新适合开发静态库在 MinGW 下链接顺序更容易出问题BUILD_opencv_worldON所有模块合成一个世界库链接时少写几十个-lopencv_*WITH_JPEG/WITH_ZLIB/WITH_PNGONimgcodecs 的图片读写后端不要为节省时间瞎关WITH_FFMPEGOFF 再 ON视频文件读取需要 FFmpeg 的 mingw64 dev 包WITH_TBBOFFparallel_for用 TBB没装独立 TBB 就不要开OPENCV_ENABLE_NONFREEON打开 SIFT、SURF 等有使用边界的算法商业项目自己判断BUILD_opencv_worldON是我最喜欢的配置。OpenCV 4.10 里有几十个模块如果不开 world每个程序都要按依赖顺序链接MinGW 对链接顺序又敏感漏一个模块就报undefined reference。开了 world 之后最终只有一个libopencv_world410.dll.a普通项目只需要这一个导入库。如果你还需要 OpenCV contrib 模块比如 xfeatures2d、dnn_onnx 这类高阶功能配置时额外加一行-DOPENCV_EXTRA_MODULES_PATHD:/opencv_contrib-4.10/modules注意 contrib 的版本号要和主源码一致4.10 的 contrib 源码要能对上主版本不然编译时头文件错位错误会非常隐蔽。至于 FFmpeg我多说一句。mingw64 编译 ffmpeg 4.4 是一套独立的活OpenCV 只是用它的头文件和库不是把 FFmpeg 源码嵌进自己。如果你手上只有 FFmpeg 的 DLL 但缺少头文件CMake 会告诉你找不到libavformat。先把 FFmpeg 的 dev 包准备好再回头用-DFFMPEG_DIR指给 OpenCV否则视频支持暂时关掉是明智的。3.3 生成器选 Ninja 还是 MinGW Makefiles决定你后面怎么哭-G MinGW Makefiles是兼容性最好的选择CLion 自带 MinGW 工具链时默认也是这一路。它生成的构建脚本由 mingw32-make 驱动依赖少任何装好 MinGW64 的机器都能跑。缺点是串行日志长编译大项目时输出刷屏错误定位要自己找。Ninja 的构建速度明显更快增量编译也干净还能自动并行调度。但前提是你给 CMake 正确传了-G Ninja并且ninja.exe在 PATH 里。OpenCV 4.10 本身对 Ninja 很友好唯一要注意的是别在 MSYS2 的 shell 里用 Ninja 同时又把/usr/bin/sh.exe放在前面一些跨平台脚本会误判 runtime。我现在的习惯是在纯 CMD 里配好 PATH用 Ninja 编 OpenCV日志短报错直接定位。不管选哪个生成器不要在 Windows 下用-G Unix Makefiles。MinGW64 虽然带着 UNIX 味道但它生成的是 Windows PE 程序Unix Makefiles 生成的是给 POSIX make 的路径规则OpenCV 的配置阶段就会崩。4. 编译与安装把 OpenCV 4.10 变成能被 g 链接的库配置成功只是开始。OpenCV 4.10 源码量不小第一次全量编译四核机器可能要等十几分钟。这时候最容易犯的错误是看到 CMake 配置完就以为装好了结果自己的工程里根本没有库可用。4.1 编译和安装命令别只跑 cmake 不跑 build配置完成后执行cmake --build build-mingw64 -j 8cmake --build会根据之前指定的生成器自动调用对应的工具不需要你手动切到构建目录敲 make。-j 8是并行编译任务数按机器核数调整一般取 CPU 核心数或一半即可。跑完后关键一步是安装cmake --install build-mingw64这条命令把 OpenCV 4.10 的头文件、导入库、DLL、CMake 包配置文件复制到CMAKE_INSTALL_PREFIX。如果你只跑 build 不跑 install后面用 find_package 会找不到包还得回来补这一步。还要注意 OpenCV 用的是单配置生成器编译 Debug 还是 Release 是在配置阶段定死的。不要在 build 命令里加--config Debug对 MinGW Makefiles 和 Ninja 没有意义。想编 Release 就配置时写-DCMAKE_BUILD_TYPERelease想编 Debug 就新建一个 build-debug 目录重新配置别共用一个构建目录。4.2 安装目录里什么该打包什么该丢install 完成后C:/opencv-4.10-mingw64目录里值得关注的是下面几类目录内容是否必须include/opencv4/opencv2所有头文件必须lib/cmake/opencv4OpenCV 的 CMake config 文件必须lib/*.dll.aMinGW64 用的导入库必须bin/*.dllOpenCV 运行时 DLL运行程序时必须带etc/模型和配置文件按需share/文档和示例工程可丢不要把 build 目录当成安装目录发给同事。build 里有大量中间文件几十个模块的.obj、测试二进制、CMake 缓存全塞过去容易把团队工程弄乱。最省心的做法是只打包 install 目录里面结构干净CMake 也能直接消费。4.3 验证编译结果的 C 最小程序编译安装完立刻写一个最小用例验证不要直接进入业务代码。这个用例要覆盖 core、imgproc、imgcodecs 三个模块能跑通就说明库的基本链路没问题。#include opencv2/core.hpp #include opencv2/imgproc.hpp #include opencv2/imgcodecs.hpp #include iostream int main() { cv::Mat gray(64, 64, CV_8UC1, cv::Scalar(0)); cv::rectangle(gray, cv::Rect(16, 16, 32, 32), cv::Scalar(255), cv::FILLED); cv::imwrite(rect.png, gray); std::cout cv::countNonZero(gray) px\n; return 0; }用 MinGW64 的 g 直接编译g -stdc17 test.cpp \ -IC:/opencv-4.10-mingw64/include/opencv4 \ -LC:/opencv-4.10-mingw64/lib \ -lopencv_world410 \ -o test.exe这里-I要指到 include 的上一级也就是include/opencv4因为代码里写的是#include opencv2/core.hpp。-lopencv_world410对应的是libopencv_world410.dll.a如果你配置时没有开 world就要把链接库换成-lopencv_core410 -lopencv_imgproc410 -lopencv_imgcodecs410并且注意顺序被依赖的库放在后面。如果编译链接都通过运行test.exe时发现找不到libopencv_world410.dll别急着重新编译先进入下一章把 DLL 路径问题处理掉。5. 避坑MinGW64 编译 OpenCV 4.10 的 5 次现场回顾下面这些问题不是理论推演都是实际编译 OpenCV 4.10 时能撞上的典型坑。每条按现象、原因、解决来记希望对你有用。5.1 sh.exe 被 PATH 提前发现构建脚本半路翻车现象CMake 配置阶段出现sh.exe was found in your PATH有时候只是黄色警告有时候后续 build 直接报找不到 shell生成的构建规则里写入了错误的命令解释器。原因机器上装过 Git Bash或者 MSYS2 的/usr/bin排在 MinGW64 的/mingw64/bin前面。CMake 在检测 MinGW 环境时发现sh.exe会把部分脚本执行方式切到 POSIX 风格OpenCV 4.10 的自定义命令用它调用 CMake 脚本就会水土不服。解决配置前先where sh.exe把 Git Bash 的usr/bin从 PATH 里临时拿掉。如果用 MSYS2配置 OpenCV 时可以在干净的 CMD 窗口里执行而不是在 MSYS2 终端里。Ninja 对这个坑的容忍度更高如果已经清了 PATH 还报警把生成器换成 Ninja 再试。5.2 CMake 编译器测试不过MinGW64 版本和位数不一致现象配置进度条走到编译测试程序时报The C/C compiler is not able to compile a simple test program。去构建目录翻CMakeFiles/CMakeError.log里面全是找不到头文件或者链接测试失败。原因大多数情况是 PATH 里混了两套 GCC32 位和 64 位共存或者CMAKE_C_COMPILER被环境影响指到了别的用户工具链。OpenCV 4.10 的 CMake 一旦被喂给错误编译器第一批测试就废了。解决在 CMake 命令里显式指定编译器不依赖 PATH 猜测cmake -S opencv-4.10 -B build-mingw64 -G Ninja \ -DCMAKE_C_COMPILERC:/mingw64/bin/gcc.exe \ -DCMAKE_CXX_COMPILERC:/mingw64/bin/g.exe \ -DCMAKE_BUILD_TYPERelease ...指定完再看gcc -dumpmachine确认输出是x86_64-w64-mingw32。如果两个都做了还在失败把build-mingw64整个删掉重新配置因为 CMake 的检测缓存会记住第一次的错误结果。5.3 undefined reference to__imp_*你把 MSVC 的 .lib 喂给了 MinGW现象自己的程序链接时出现undefined reference to __imp_cv::imread或者__imp_cv::Mat看起来函数名都对就是链接不上。原因MinGW64 链接 DLL 时找的是 MinGW 格式的导入库通常是libopencv_world410.dll.a。官方 OpenCV 预编译包给的是opencv_world410.lib那是 MSVC 的 COFF 格式导入库g 能识别一部分但符号修饰方式不同最后只剩__imp_后面一堆乱名。解决检查C:/opencv-4.10-mingw64/lib下是否有.dll.a文件。没有就确认自己编译时确实跑过cmake --install。链接时只写-lopencv_world410CMake 会自动映射到libopencv_world410.dll.a。如果你非要用官方预编译包MinGW 的官方答案是不行。5.4 程序启动缺 DLLOpenCV 4.10 主库和第三方库分开走现象链接成功运行 exe 时先弹libopencv_world410.dll is not found。把 OpenCV 的 bin 目录加进 PATH 后又弹libgcc_s_seh-1.dll not found再弹libstdc-6.dll not found。原因Windows 下 MinGW64 编译出的程序不依赖 MSVC CRT但依赖 GCC 自己的运行库。OpenCV 的 DLL 用了 MinGW64 工具链运行期还需要libgcc_s_seh-1.dll、libstdc-6.dll、libwinpthread-1.dll它们一般在C:/mingw64/bin里。编译机上有 PATH 看不见问题换一台干净机器就原形毕露。解决发布程序时把 OpenCV 的 bin 目录下所有 DLL以及 MinGW 的这几个运行时 DLL 一并复制到 exe 旁边。不要只复制 OpenCV 的 DLL。如果在意体积可以给 g 加-static-libgcc -static-libstdc把 C 运行库打进 exe但 OpenCV 自身的 DLL 仍然要带上。5.5 Debug 和 Release 配置混用图像内存离奇崩溃现象代码在 Debug 配置下跑得正常Release 配置下偶尔崩溃或者反过来。崩溃点有时在cv::Mat的拷贝构造有时在std::vector扩容位置飘忽不定。原因你的程序和你链接的 OpenCV 库不是同一套构建配置。MinGW64 在 Debug 与 Release 下的 STL 诊断、内联、内存布局有差异两边混用后对象在一个配置里构造在另一个配置里析构堆管理不匹配就会炸。解决OpenCV 库用什么配置业务工程也用什么配置。如果业务工程必须用 Debug就单独建一个 build-mingw64-debug用-DCMAKE_BUILD_TYPEDebug重编一套 OpenCV。两套库的目录不同通过OpenCV_DIR切换。不要为了省编译时间让两个配置共享同一套 OpenCV DLL这个坑很隐蔽一旦出现你会在业务代码里浪费大量时间。6. 进阶把 MinGW64 的 OpenCV 4.10 接进 CLion 和 Qt 工程基础库编完真正的工作才开始。把 OpenCV 4.10 接进 CMake 工程时我会固定用一套模板避免每次重找头文件和库路径。6.1 CMakeLists.txt 里 find_package(OpenCV 4.10) 的写法cmake_minimum_required(VERSION 3.20) project(hello_cv CXX) set(CMAKE_CXX_STANDARD 17) set(CMAKE_CXX_STANDARD_REQUIRED ON) set(OpenCV_DIR C:/opencv-4.10-mingw64/lib/cmake/opencv4) find_package(OpenCV REQUIRED) add_executable(hello_cv main.cpp) target_link_libraries(hello_cv PRIVATE ${OpenCV_LIBS}) target_include_directories(hello_cv PRIVATE ${OpenCV_INCLUDE_DIRS})OpenCV_DIR必须指向包含OpenCVConfig.cmake的目录一般是lib/cmake/opencv4而不是 install 根目录。只要 find_package 成功OpenCV_LIBS会自动带入 world 库OpenCV_INCLUDE_DIRS会带入正确的 include 路径。CLion 里配置 CMake 工具链时选 MinGW64把这个 CMakeLists 放进去就能跑。6.2 运行时 DLL 路径我固定用的 app 目录结构我在项目里会建一个dist目录把运行时依赖全部复制过去避免每次启动前改 PATH$dst .\dist Copy-Item C:/opencv-4.10-mingw64/bin/*.dll $dst Copy-Item C:/mingw64/bin/libgcc_s_seh-1.dll $dst Copy-Item C:/mingw64/bin/libstdc-6.dll $dst Copy-Item C:/mingw64/bin/libwinpthread-1.dll $dst这样发布时只需要打包dist目录和 exe。如果以后要接 Qt记得把 Qt 的 mingw 构建目录里那几个 DLL 也加进去并且确保 Qt 和 OpenCV 用的是同一套 MinGW64 工具链否则 Qt 元对象系统和 OpenCV 的 Mat 数据互相传递仍会踩 ABI 问题。我现在每次换 MinGW64 版本或 OpenCV 补丁版本都会先跑一遍这个最小 CMake 工程确认 find_package、DLL 拷贝、cv::Mat 初始化都过了再进业务代码。这个习惯帮我少排查了很多为什么上一版能跑这一版不能跑的问题。希望帮到你。本文还有配套的精品资源点击获取