简介面向需要在Windows环境下借助MinGW工具链编译OpenCV 4.8.0的开发者压缩包提供了完整编译产物与配套文件。OpenCV作为开源计算机视觉与机器学习库DNN模块、图像处理及视频分析能力在本版本中均有显著改进MinGW编译版本免去自行配置CMake、FFmpeg、TBB等依赖库和构建参数的繁琐流程可直接集成到本地C项目中。资源包共2000个文件以cpp源文件750个、hpp头文件317个与Python脚本222个为主同时涵盖Java、HTML文档、XML配置及测试用例覆盖编译结果、示例程序与接口声明多个层面整体约282.62MB。已有330人下载学习适合中高级C开发者用于二次开发、源码研读或作为Windows端计算机视觉项目的基础依赖。1. 为什么在 Windows 上编译 OpenCV 4.8.0 偏偏要选 MinGW在 Windows 上把 OpenCV 4.8.0 和 MinGW 凑到一起是我这几年做 Qt 混合开发踩过最值回票价的坑之一。官方预编译包只跟 MSVC 绑定你用 Code::Blocks、Dev-C 或者 Qt 自带的 MinGW 套件去链接头文件虽然能过但链接阶段就会在各种奇怪符号上翻车——不是报一堆 unresolved external symbol就是程序运行时直接崩掉玄学得很。这篇文章把 OPENCV4.8.0MINGW编译 的完整路径拆开讲从 MinGW-w64 选型、CMake 配置到编译安装再到集成进自己的 CMake 或 .pro 工程最后是五个我反复踩过的坑。适合不想被 MSVC 绑定、需要干净 GCC 环境交付 C 程序的工程师也适合在离线环境里要把官方源码吃透的同事。2. 编译前的工具链MinGW-w64 版本、CMake 生成器与依赖项取舍2.1 MinGW-w64 与 MSVC 到底差在哪决定你用哪种构建链OpenCV 官方在 Release 页面给的是opencv-4.8.0-windows.exe解压后里头的 lib 用的是 MSVC 的 C ABI跟 MinGW 的 Itanium ABI 完全不互通。头文件一致没有用二进制接口对不上链接器第一个不答应。所以你自己编本质是要一份和 MinGW 的 GCC 编译器完全匹配的二进制。MinGW 版本这里没有纠结的余地我一般直接推荐 MinGW-w64 的 12.x 系列选posix-seh前缀。为什么不要win32线程模型OpenCV 4.8 内部虽然大量用 Win32 线程但你一旦配合 Qt 的 MinGW 套件或者在自己的代码里写std::threadwin32 模型的 C 标准库缺了 pthread 包装编译能过运行到std::thread相关路径就会直接崩溃。备好工具链后在命令行里验证g --version cmake --versionGCC 版本输出如果是 8.0 以下OpenCV 4.8 里部分新特性比如对 C17 的依赖会报错。我建议至少 8.1最好直接上 12.x。还有一点下载时要分清 x86_64 和 i68664 位项目别拿 32 位编译器硬顶后面链接会死得很难看。2.2 CMake 生成器选择MinGW Makefiles 还是 NinjaCMake 在 Windows 下的生成器决定了你用什么命令去驱动编译。最省事的是-G MinGW Makefiles它直接生成Makefile然后用mingw32-make编译。这个方案的好处是流程直观出问题好追踪适合第一次做 OpenCV 编译的人。Ninja 更快但有个前提CMake 必须能找到一套完整的 GCC 工具链。用 MinGW Makefiles 时CMake 有时会自己从 PATH 里抓编译器用 Ninja 时一旦抓错后面全是奇怪的编译错误。我在 Windows 上开 Ninja 时会显式指定-DCMAKE_C_COMPILERD:/mingw64/bin/gcc.exe -DCMAKE_CXX_COMPILERD:/mingw64/bin/g.exe -DCMAKE_MAKE_PROGRAMD:/mingw64/bin/ninja.exe另外同一个构建目录换生成器是天坑CMakeCache.txt会把上一次的编译器路径记住。你要从 MinGW Makefiles 切 Ninja必须把整个 build 目录删掉重来没有后悔药。2.3 依赖项取舍Python、IPP、TBB 哪个值得要OpenCV 默认开启的依赖比你想象得多。如果你只是做 C 桌面程序Python 绑定、Java、Node.js 这堆全都可以关掉。我一般在 CMake 配置阶段就显式关掉省编译时间也省心。Intel IPP 是最容易被忽略的卡点。WITH_IPPON时 CMake 会去拉一个 IPPICV 压缩包网络不好就卡在IPPICV: Downloading那里十分钟不动。对普通项目来说 IPP 只是少数核心函数加速你完全可以直接-DWITH_IPPOFF。TBB 是线程调度库Qt 自带的环境不见得匹配我一般也关掉OpenCV 的默认并行在 Windows 下一样能跑多核。最终依赖就剩两项CMake 能看到的 MinGW以及一个干净的英文路径。内网环境再补一步——OpenCV 源码里部分第三方库会在配置阶段从 GitHub 拉取你需要提前把源码包准备好放到构建缓存目录里CMake 检查哈希通过才会用本地包。选项推荐值理由WITH_IPPOFF避免下载 IPPICV普通场景感知不到差异WITH_TBBOFF规避 TBB 与 MinGW 的线程模型噪音BUILD_TESTS / BUILD_PERF_TESTSOFF省掉大量测试源文件编译BUILD_opencv_python3OFF纯 C 场景没必要生成 Python 模块3. 用 CMake 跑通 OPENCV 4.8.0 MinGW命令与参数逐项拆解3.1 目录规划与源码准备源码、构建、安装三个目录分开这是我从一开始就坚持的习惯不然你会在清理临时文件时误删源码。我一般是这样摆D:/opencv-4.8.0 源码解压目录 D:/opencv-4.8.0-build 构建目录CMake 生成的文件全在这 D:/opencv_mingw 安装目录include、lib、bin 最终落这目录名绝对不要出现空格和中文MinGW 对路径解析有自己的脾气build放在D:/My Documents下时CMake 那层明明过去了mingw32-make却会在某个头文件路径上莫名其妙失联。源码解压完成后确认根目录下有CMakeLists.txt然后检查 PATH 里能不能找到mingw32-makewhere mingw32-make where g如果输出指向多个版本的编译器后面的坑会接踵而至。我见过机器上有 Code::Blocks 的 MinGW 和 Qt 的 MinGW 两套工具链结果 CMake 抓到一套Makefile 跑到一半又调另一套最后原因是 PATH 顺序。解决方式是把你要用的那个bin目录放到 PATH 最前面。3.2 CMake 配置命令逐项拆解下面这组命令是我在 OpenCV 4.8.0 上反复验证过的底线配置按下就会进入编译环节cmake -S D:/opencv-4.8.0 -B D:/opencv-4.8.0-build \ -G MinGW Makefiles \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIXD:/opencv_mingw \ -DCMAKE_MAKE_PROGRAMmingw32-make \ -DBUILD_TESTSOFF \ -DBUILD_PERF_TESTSOFF \ -DBUILD_EXAMPLESOFF \ -DBUILD_opencv_python3OFF \ -DBUILD_JAVAOFF \ -DWITH_IPPOFF \ -DWITH_TBBOFF \ -DBUILD_SHARED_LIBSON-DBUILD_TYPERelease必须放在命令里MinGW 的 Debug 和 Release 在代码优化和运行速度上差距明显OpenCV 默认构建类型是空CMake 会甩给你一个带Debug后缀的库名后面链接时你对着opencv_core找半天也找不到。-DCMAKE_INSTALL_PREFIX决定最终安装位置。这个目录要有心理准备它会产生几百 MB 甚至更大的输出。-DBUILD_SHARED_LIBSON是生成 DLL 的如果你的目标是一个免部署的独立 exe这一项可以改成OFF但编译时间和最终文件体积都会变大后面第 5 章我会具体说。配置过程最后会打印一张配置表重点关注C compiler那行是不是你指定的 MinGW 路径以及OpenCV modules列表是否完整。如果出现CMake Error: Could NOT find PThread之类通常不是真的找不到而是编译器路径错位。3.3 编译安装命令与 CPU 多线程加速配置通过后直接执行构建。我常用 CMake 自带的构建命令它比直接跑mingw32-make更灵活cmake --build D:/opencv-4.8.0-build -j 8-j 8是并行线程数。MinGW 的 g 编译单个文件时的内存消耗比 MSVC 大物理内存 8G 的机器建议-j416G 再考虑-j8。我见过有人直接-j$(nproc)在 Windows 下 nproc 返回的核数往往虚高编译到一半cc1plus.exe直接崩溃。编译过程中你会看到各种Building CXX object modules/core/...第一次完整编译二十到三十五分钟很正常。编完后执行安装cmake --install D:/opencv-4.8.0-build安装完成后D:/opencv_mingw下应该出现include/opencv2、lib和bin。lib里是libopencv_core408.dll.a这种名字bin里是opencv_core408.dll这种运行时库。看到这个命名结构说明你的 OPENCV 4.8.0 MinGW 编译已经走通了。4. OPENCV 4.8.0 MinGW 编译避坑5 条实测踩坑记录4.1 配置阶段卡在 IPPICV 下载或下载后校验失败现象CMake 输出里卡在IPPICV: Downloading ippicv_2020_...十几分钟没动静最后报 hash 不一致或超时。原因OpenCV 4.8.0 的WITH_IPPON会通过外网拉取 IPPICV 包网络不稳定时会下载到一半的残包CMake 检测哈希失败就反复重试玄学一样。解决配置命令里直接-DWITH_IPPOFF一劳永逸。如果项目性能测试真的需要 IPP就去互联网找一个和你版本匹配的 IPPICV 压缩包手动放到源码目录的.cache/ippicv下并设置-DOPENCV_IPP_LOCATIOND:/path/to/ippicv。对绝大多数业务场景关闭 IPP 的损失可以忽略。4.2 编译到一半内存不足或cc1plus.exe崩溃现象并行编译进行到某个.cpp文件时命令行弹出黑框然后消失回看日志是fatal error: cannot allocate memory或internal compiler error。原因MinGW 的 g 每个编译单元都要开独立进程-j开太大物理内存被瞬间耗空。Win 任务管理器能看到多个cc1plus.exe各占几百 MB。解决把并行数降到物理核心数的一半。我的经验是 16G 内存用-j4比较稳32G 才敢上-j8。另外加上-DBUILD_TESTSOFF -DBUILD_PERF_TESTSOFF可以少编不少大文件间接降低内存峰值。4.3 链接时报undefined reference to cv::imread等一堆符号现象自己的代码编完了链接时一堆undefined reference to cv::imread、cv::waitKey。原因MinGW 的 GNU 链接器在处理静态库时是从左到右扫描的你的源文件在所有库之前库之间的顺序也有讲究。imgcodecs依赖imgprocimgproc依赖core如果你写的顺序是-lopencv_core -lopencv_imgproc -lopencv_imgcodecs后面的库引前面已扫过的库符号可能找不到。解决按依赖顺序从 core 到 imgproc 再到 imgcodecs 排列或者直接把所有模块链接成一个库编译时加-DBUILD_opencv_worldON链接时只写-lopencv_world。对于自己搭 CMake 的新手我强烈建议开 world 模式省掉排库顺序的烦恼。4.4 Qt 里出现cannot find -lpublic现象在用 Qt 的 MinGW 套件编译 OpenCV 项目时链接错误显示cannot find -lpublic但你根本没写过 public 库。原因这是.pro文件里LIBS变量书写不当引起的。比如写了多行LIBS -lopencv_core前一行末尾没有续行符下一行开头又恰好是从某个变量展开的public比如路径里带/public/qmake 会把它解析成-lpublic。解决写 QMake 工程时不裸拼-l参数改成LIBS -LD:/opencv_mingw/lib -lopencv_world并且保证这行后面没有杂项。如果你把D:/opencv_mingw/bin也放进过LIBS那是找错地方了bin目录只管运行时 DLL编译期链接只用lib。4.5 CMake 报sh.exe was found in your PATH现象配置阶段 CMake 直接弹错sh.exe was found in your PATH. MinGW Makefiles do not work when sh.exe is in your PATH。原因你的 PATH 里存在 Git Bash 或其他工具带的sh.exeMinGW Makefiles 生成器检测到后会拒绝工作因为它在 Makefile 里调用的 shell 会与 sh 冲突。解决配置 OpenCV 时把 Git 的usr/bin从 PATH 里临时去掉或者给 CMake 传一个空值-DCMAKE_SHCMAKE_SH-NOTFOUND用这个参数后 CMake 会跳过 sh 检测然后正常生成 Makefile。注意这只对 MinGW Makefiles 生效Ninja 生成器没有这个限制。5. 编译产物集成CMakeLists.txt 引用与第一个可用程序5.1 最小工程示例指定 OpenCV_DIR 与 find_packageOpenCV 安装到D:/opencv_mingw后目录里会有 一个OpenCVConfig.cmake。你的工程要找到它通常两种方式一种是在 CMakeLists 里写死路径另一种是配置时传OpenCV_DIR。我推荐在 CMakeLists 里写 PATHS方便换机器时一眼看懂cmake_minimum_required(VERSION 3.10) project(opencv_demo) set(CMAKE_CXX_STANDARD 11) set(OpenCV_DIR D:/opencv_mingw) find_package(OpenCV REQUIRED) include_directories(${OpenCV_INCLUDE_DIRS}) add_executable(demo main.cpp) target_link_libraries(demo ${OpenCV_LIBS})find_package(OpenCV REQUIRED)在你没有给OpenCV_DIR时会去系统常见路径找。MinGW 装完的 OpenCV 不在 CMake 的默认搜索列表里所以显式设置最靠谱。OpenCV_INCLUDE_DIRS指向D:/opencv_mingw/include而${OpenCV_LIBS}会展开成一系列libopencv_core408.dll.a的绝对路径。对应的main.cpp只需要做一件事——打开一张图看是否有像素#include opencv2/opencv.hpp #include iostream int main() { cv::Mat img cv::imread(test.png); if (img.empty()) { std::cerr image not loaded\n; return 1; } std::cout img.size() img.type() \n; return 0; }这样验证整条工具链是否真的通比跑人脸检测那些示例省力得多。5.2 区分 shared 与 staticMinGW 下 lib 和 dll 怎么配默认编译出来的是动态库lib目录下是libopencv_core408.dll.a它只是一个导入库真正的代码在bin/opencv_core408.dll里。链接时可以链导入库运行时必须找到 DLL。如果编译时设了-DBUILD_SHARED_LIBSOFF那么lib目录下是一批巨大的静态库比如libopencv_core408.a。链接后你的 exe 就不依赖 OpenCV 的 DLL但 MinGW 的运行时 DLL 仍然免不了——这块取决于你的线程模型和异常模型。我给项目的建议是内部工具用共享库编译快、迭代方便交付给客户的单文件工具用静态库省去带一坨 DLL 的麻烦。需要静编时CMake 配置加-DBUILD_SHARED_LIBSOFF其他步骤完全一样但全模块静态链接后 exe 会膨胀到一两百 MB这是正常现象。5.3 运行期依赖把 bin 目录加入 PATH 或在 exe 同目录放 DLL刚链接出来的 exe 双击运行最常弹出的错误是找不到 opencv_core408.dll。治标的方法是设置环境变量set PATHD:/opencv_mingw/bin;%PATH% demo.exe治本的方法是把需要的 DLL 拷到 exe 同目录。拷贝前先查一下你的 exe 到底依赖哪些 DLLobjdump -p demo.exe | grep DLL Name输出里除了 OpenCV 的 DLL还会有libgcc_s_seh-1.dll、libstdc-6.dll和libwinpthread-1.dll。这三兄弟是 MinGW 运行时目标机器没有 MinGW 环境时也必须一起带走。我见过同事只拷了 OpenCV DLL拿到没有装 mingw 的电脑上还是报缺libgcc_s_seh-1.dll就是因为缺了这个检查步骤。6. 进阶玩法只编译你真正需要的模块并验证输出是否正确6.1 用 BUILD_LIST 把配置时间从半小时压到 5 分钟OpenCV 全模块编译有二十多个 modules如果你的项目只用core、imgproc、imgcodecs完全可以用BUILD_LIST锁定范围。我在做图像读写工具时就靠这一招省时间cmake -S D:/opencv-4.8.0 -B D:/opencv-4.8.0-build \ -G MinGW Makefiles \ -DCMAKE_BUILD_TYPERelease \ -DCMAKE_INSTALL_PREFIXD:/opencv_mingw_min \ -DBUILD_LISTcore,imgproc,imgcodecs \ -DWITH_IPPOFF \ -DBUILD_TESTSOFFBUILD_LIST用逗号分隔不要加空格。这样构建目录里只会出现列出的模块的构建项OpenCV 主 CMakeLists 仍然会配置整个框架但编译文件数量减少一半以上。如果你的需求再加一个videoio把模块名追加进去即可。6.2 用 Ninja 和 ccache 把重复编译时间减半改 OpenCV 源码想快速验证时Ninja 和 ccache 是绝配。Ninja 的增量构建比 MinGW Makefiles 快ccache 则直接缓存编译输出。我一般这么做cmake -S D:/opencv-4.8.0 -B D:/opencv-4.8.0-build \ -G Ninja \ -DCMAKE_C_COMPILERD:/mingw64/bin/gcc.exe \ -DCMAKE_CXX_COMPILERD:/mingw64/bin/g.exe \ -DCMAKE_C_COMPILER_LAUNCHERccache \ -DCMAKE_CXX_COMPILER_LAUNCHERccache \ -DCMAKE_BUILD_TYPEReleaseccache 需要先安装在系统里并让 CMake 能找到它。首次编译和普通编译一样慢第二次开始命中缓存的编译单元几秒钟就过。不过要注意ccache 对编译器参数敏感改编译选项会大量失命中这个概念别当成普通缓存。6.3 验证 OpenCV 是否正常用 getBuildInformation 看配置编译完不等于万无一失。我每次拿到一套新编译产物都会先跑一个小程序打印cv::getBuildInformation()#include opencv2/opencv.hpp #include iostream int main() { std::cout cv::getBuildInformation() std::endl; return 0; }输出里重点看三行。第一处是Compiler字段如果后面写的是GCC而不是MSVC说明这套库确实是 MinGW 产物。第二处是Media I/O段落看有没有FFMPEG和GStreamer这会直接影响你能不能读视频。第三处是Parallel framework如果是空或Win32 threads说明并行部分已纳入默认后端。我现在的习惯是任何 OpenCV 编译完成后先跑这个信息打印再往下写业务代码。它能一眼暴露编译器混用、模块缺失、FFMPEG 没编进去三种最隐蔽的问题比跑一百张图片更管用。希望这一套流程能让你少走我走过的弯路也希望帮到你。本文还有配套的精品资源点击获取