OpenCV MinGW include path: fix no such file for core.hpp

A Windows build with MinGW dies on the first OpenCV header, before a single line of your own code compiles. The message names the header and nothing else, so it reads like a mystery; it is not. It is a plain statement that the compiler walked every directory on its include search path and never found the exact relative path your #include line spelled. This guide shows how to read that search, which of the four usual causes you have, the fix step by step, and the CMake route that ends this class of error for good.

Read the error as a search result

When g++ meets #include "opencv/core/core.hpp", it does not search the disk. It joins that relative path onto one directory after another: first the folder holding array.cpp, then every directory on the project's include path, then the compiler's own stock roots. The first directory where the joined path exists wins; if none does, you get exactly this:

C:\My C++ Projects\array.cpp|1|fatal error: opencv/core/core.hpp: No such file or directory|

The message therefore says two things at once: either the relative path is spelled wrong, or the root that contains it was never on the list. In a fresh MinGW project it is usually both. Nothing is corrupt and nothing is locked; the join simply never lands on a file.

The four causes, most likely first

1. The include line spells a folder no OpenCV release ships. OpenCV 2.4 puts the C++ header at opencv2/core/core.hpp and keeps the old C API under plain opencv/, where cv.h lives — not core.hpp. OpenCV 3 and 4 use opencv2/core.hpp. The prefix-less opencv/core/core.hpp matches nothing in any release, and neither does a tree copied into C:\MinGW\include\opencv, because that nesting is wrong too. Test: dir /s /b C:\opencv\*core.hpp, then compare the printed path with your include line character by character.
2. The include root is not on the search list at all. A downloaded source tree is not an installed library; nothing has wired it into the build yet. Test: the preprocessor-only verbose run in step 6 below prints the live #include <...> search starts here: block — your root is on it or it is not. The same failure with a vendor SDK's headers is walked through in Camera SDK missing OpenCV headers: causes, tests and fixes.
3. The root was added to one configuration only. Debug links, Release fails, or the reverse. Test: clean-build both configurations and note which one breaks.
4. A different compiler is doing the build. IDEs with several registered toolchains happily invoke a g++ whose stock roots you never touched. Test: the version banner of the verbose run names the exact compiler.

Fix it in order

Worked example, with the path joins spelled out:

OpenCV built from source, CMAKE_INSTALL_PREFIX=C:/opencv/install

Header on disk   C:/opencv/install/include/opencv2/core.hpp
Include line     #include <opencv2/core.hpp>
Root to add      C:/opencv/install/include
Join             root + relative path
                 = C:/opencv/install/include/opencv2/core.hpp
                 exists, so the preprocessor passes

Same file, original line, stock roots only:
Root tried       C:/MinGW/include
Join             C:/MinGW/include/opencv/core/core.hpp
                 does not exist: fatal error, No such file or directory

1. Locate the real header. In a command prompt run dir /s /b C:\opencv\*core.hpp (MSYS: find /c/opencv -name core.hpp). The folder one level above opencv2 is your include root. Some layouts add a level, such as include/opencv4/opencv2 under MSYS2; the rule holds — the root is whichever folder directly contains opencv2.
2. Spell the include the way that tree does: opencv2/core.hpp on OpenCV 3 or 4, opencv2/core/core.hpp on 2.4. Fixing the missing 2 alone clears the error on an already-correct search path.
3. Add that root to the project's compiler search directories in every configuration — the include-path page of the build options in your IDE, set at project level so Debug and Release inherit it. On the command line: -IC:/opencv/install/include. Forward slashes work in g++ and need no escaping.
4. Wire the linker side while you are there: the install's lib folder into the linker search directories, the core module's import library into the link list. In a MinGW-built install the file name begins with libopencv_core.
5. Make the runtime DLLs reachable: copy them from the install's bin folder beside your .exe, or prepend that bin folder to PATH while you develop.
6. Prove the header stage is closed before touching the link line: g++ -E -v array.cpp -o NUL (MSYS shells write -o /dev/null). Verbose mode prints the search list and then preprocesses the file; no fatal error means the include path is right.

The cleaner route: let CMake carry the paths

Hand-maintained include lists rot: one new machine or one new teammate and they are wrong again. A ten-line CMakeLists.txt carries them instead, and an OpenCV install ships a CMake package description that fills every path automatically:

cmake_minimum_required(VERSION 3.10)
project(array_demo CXX)

find_package(OpenCV REQUIRED)

add_executable(array_demo array.cpp)
target_include_directories(array_demo PRIVATE ${OpenCV_INCLUDE_DIRS})
target_link_libraries(array_demo PRIVATE ${OpenCV_LIBS})

Configure and build with:

cmake -G "MinGW Makefiles" -B build
mingw32-make -C build

If find_package(OpenCV REQUIRED) still cannot find the package although OpenCV is installed, hand it the install folder as a cache entry: -DOpenCV_DIR="C:/opencv/install". For SDK sample code you inherited, CMake can't find OpenCV in SDK samples walks that same fix. A build that links most modules but misses one, such as aruco, is a narrower case: the aruco module fix covers it.

If the machine has no MinGW-targeted OpenCV, build it once: from an empty build folder beside the sources, configure with the MinGW Makefiles generator, run mingw32-make -j4 to use four cores, then mingw32-make install from that same build folder. Budget roughly 20 GB of free disk space for the build tree and install. A full build typically runs 20-60 minutes on a four-core desktop; switching off the test and app targets in the CMake GUI cuts a large share of it.

Why copying headers into the compiler's folders always fails

Dropping headers into C:\MinGW\include\opencv feels faster and fails three ways. The nesting never matches a shipped release, so the same error returns. Headers were never the whole problem: without import libraries and DLLs the next two stages cannot start, and libraries do not belong in a compiler's include tree. And that tree is disposable — the next compiler update or reinstall deletes your edit silently. Keep the compiler stock and give each OpenCV version its own install folder. The reflex is not MinGW-specific: this MPASM include-file syntax fix shows the same mistake and the same fix in a PIC assembler toolchain.

The errors that come after the header error

Undefined references to cv::... mean preprocessing passes and linking fails. Either the lib folder or the import library is missing from the link line, or you are feeding MinGW the Visual Studio libraries from the prebuilt package. Check architecture while you are there: the linker prints skipping incompatible when the OpenCV build is 64-bit and your compiler 32-bit, or the reverse. CMake missing dependency diagnostics for vision builds extends the method to larger dependency sets.

The exe closes immediately, or Windows reports a missing DLL — that is the load stage: the DLLs in the install's bin folder were never found. Copy them beside the exe or add the folder to PATH. The startup-time view of the same fault, with the process-level tests, is in Vision application startup error: diagnose missing DLLs.

The decision for your case

• One machine, one project, you own the toolchain: correct the spelling, add the root to both configurations, link, done — the six steps above are a ten-minute job. Move to CMake when a second project or machine appears.
• A team on several machines: standardize on CMake now. Hand-edited IDE paths are a recurring cost; a CMakeLists.txt is written once and works everywhere.
• A production cell: do not hand-patch the toolchain on factory hardware. Match the controller to your software plan: vision controllers ship two ways, with the vendor vision-suite license included or without a license key for your own OpenCV and MinGW stack.

The MV-VC3301H-128G66 is the first kind: a Core i3-8100 with 8 GB of RAM and a 128 GB SSD, with the VM6200Pro license included. The MV-VC4712-256G10-2TH is the second: an Ultra 7 255H with 16 GB × 2 of RAM, a 256 GB SSD and a 2 TB HDD, without a license key — the one you image with your own toolchain.

If the C++ you are compiling reads frames from area scan cameras, size the whole chain — cameras, lighting, controller — in one pass with the configurator.

Pre-build checklist

• Include spelling matches your version: opencv2/core.hpp on 3 and 4, opencv2/core/core.hpp on 2.4 — the most common miss.
• One include root per OpenCV version, pointing at the folder that directly contains opencv2, set at project level so both configurations inherit it.
• The install's lib folder and the core import library on the linker side of the same configurations.
• DLLs from the same build beside the exe or on PATH.
• Compiler and OpenCV build both 64-bit or both 32-bit; mismatches print skipping incompatible.
• The compiler's own include tree untouched.
• A clean g++ -E -v run before any link-line work.

Building this stack onto factory hardware? Tell us what you are compiling for through /contact/, and we will help you size the controller and camera chain around it.