I build successfull under Win11 OpenCV Version 12 as release and as debug version with CUDA.
Every build takes about 8 hours and on the end I got a 1,5 GB DLL for release, everything with that is fine. But the debug build creates a DLL slightly bigger than 2GB andere even the progs from build/bin like opencv_versiond.exe shows an error that they can’t execute because of world DLL has an error. My guess is that it is too big. Everything is 64 Bit, I have enough RAM etc. Can it be possible that it is too big ? And any tipps how to shrink ? I mean every build is 8 hours , when I start try to take less “WITH…” options I need days 
I think I know what you mean. In earlier attempts when I was trying to make my own build (with cuda), I was waiting 10 hours to get it compiled, just to get a lot of errors, having gigabytes of wasted hard disk space (I forgot if it was 10GB or 40GB) and failing to build opencv_world in the end.
Three weeks ago I found here in forum the installation guide made by user cudawarped. After manually removing the python stuff and adding OpenMP support, It took like 2-3 hours to compile opencv 4.11.0 and all together it takes 1GB, half of them are test/perf exe files. The opencv_world4110.dll is about 250MB, the debug version 350MB and they work.
I wish he would add the advice to build the debug version before the release version or the samples exe files will overwrite the release exe’s. I would also like to know if there’s a way to add the set CMAKE_BUILD_PARALLEL_LEVEL=<N_THREADS> aswell as the parameter -G"Ninja Multi-Config" to cmake_gui, because it’s still a bit more comfortable.
1 Like
I can’t translate the screen shot but the reason the DLL is so big and that the compile time is so long is that you are building for lots of different compute capability devices. If you only build for your device (e.g. -DCUDA_GENERATION=Auto) then the DLL will be much much smaller. The compile time can be futher reduced by using the Ninja build system as described in the guide mentioned above.
You can raise an issue on github with any comments suggestions and I’ll take a look.
As you know from the guide I don’t recommend the GUI because it makes it much much harder for me to debug any issues someone might have. Additionaly CUDA reconfigurations through the GUI can be problematic. That said you can select Ninja Multi-Config as the generator when you first click Configure if you launch cmake-gui from the Visual Studio developer prompt and you can add any parameters you like by clicking + Add Entry.
Note: CMAKE_BUILD_PARALLEL_LEVEL is only applicable when using the Visual Studio generator not Ninja. Its also still a lot lot slower than Ninja.
0xc000007b, as an NTSTATUS value, means STATUS_INVALID_IMAGE_FORMAT
{Bad Image}
%hsis either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.
Error status0xc0000xxx.
we can guess a lot.
32 bit sounds like a good guess. google has a bunch of that in relation to the 7b error.
an english variant of that error would be:
the description seems to be identical for error 0xC000012F and 0xC000007B
google assumes that this error mostly occurs when mixing 32 and 64bit
messages may be similar, and all are related to “bad images” (dll/exe are “images”) but 12f should have had its own message. the screenshot you found on the net puzzles me.
0xC000012F
STATUS_INVALID_IMAGE_NOT_MZ
The specified image file did not have the correct format: it did not have an initial MZ.
Wow, I just tried it from the commandline , not cmake-gui and it works much better, already compiled and Debug works. Great Thanks ! Just another silly question … where are alle the include files when I build from source ? I now used it from a prebuild download, but I guess there are not exactly the same. In all the “include” paths below my git checkut there only one hpp file or only cmake files, nothing in the build dirs either. In only got libs and the DLL.
1 Like
if you made it like this
cmake.exe --build x:\targetdir\opencv-4.11.0/ --target install --config Release
there should be an “install” folder within that dir with all you need
1 Like
I swear “install” wasn’t there as I use cmake-gui and VS2022 (open the sln and F7), but now after doing everything from the commandline “Install” is there with everything inside. I lso did a search with the wise-search tool which find everything 
Before the commandline build I find the libs/DLL’s under bin and lib but no include. So the lessson … back to commandline as always. I must say I’m a linux guy since the beginning 90’s but in this case, with so many options in opencv I used cmake-gui , to have a list of all options and short desc of every option.
no, after cmake was creating your sln file for VS and you opened it, you should see something like ALL_BUILD and INSTALL in your “Projektmappen-Explorer”, you can set it as start project or build with a right-click in debug and release mode and it will create the install folder
I also don’t know why you opened your DLL files with a hex editor, this MZ only means that it’s a microsoft executable/dll and exists since MS-DOS
I open it with a HEX Editor because crackwitz wrote something with:
STATUS_INVALID_IMAGE_NOT_MZ
And I want to show you that it has MZ as first 2 Bytes, that’s the only reason.
If somebody else have the same problem my guess is still the size slightly over 2 GB The final solution for me is building a smaller one with all the tips and hints here:
Build OpenCV (including Python) with CUDA on Windows: Comprehensive Guide including Python Bindings, cuDNN, and Nvidia Video Codec SDK
1 Like
if (if!) size really is the issue (I don’t see clear evidence of this), then do not build a world dll. the normal way is to have a dll per module.