OpenCV 2-4-6 MInGW Binaries and Latest MinGW Release (Bug #3342)
| Status: | Cancelled | Start date: | 2013-10-23 |
|---|---|---|---|
| Priority: | Normal | Due date: | |
| Assignee: |  Roman Donchenko |
% Done: | 30% |
| Category: | build/install | ||
| Target version: | 2.4.9 | ||
| Affected version: | 2.4.0 - 2.4.6 | Operating System: | Windows |
| Difficulty: | HW Platform: | x64 | |
| Pull request: |
Description
Hi there, a while back I was TAing a computer vision course using OpenCV and as part of it I wrote a tutorial for installing OpenCV on Windows with Code::Blocks and MinGW, it was a pretty basic tutorial basically just showing how to setup a project tell it how to link opencv and add it to the system path etc. I simply used the latest MinGW and the pre-built windows binaries, afterwards I decided to share the tutorial on my website and all was great. (this was circa opencv 2-4-3 era)
Recently I've started getting lots of comments saying it wasn't working and people were having problems so I begrudgingly fired up windows again to check my tutorial using the latest mingw and opencv expecting to find it worked and that people were simply not following instructions properly. However I received the same bug that others were experiencing "application was not able to start correctly (0xc0000005) I dug around and it looks like the problem has to do with the dlls OpenCV is expecting MinGW to have and what the latest MinGW actually has. Anyways a quick rebuild of opencv on my local machine and everything works fine (its a total vanilla windows install with the latest minGW).
What I am trying to figure out is what is different between my built binary and the one in the release. Looks like it could be related to this: http://answers.opencv.org/question/3740/opencv-243-mingw-cannot-run-program/.
Can someone provide details with respect to how the pre-built binaries are built? Is it possible that the build machine needs to update its mingw install? Or is there a reason for doing otherwise? Or is there another recommended way for using opencv on windows these days?
This also looks vaguely related to these 2 issues:
http://code.opencv.org/issues/3214
http://code.opencv.org/issues/3015
Associated revisions
Merge pull request #3342 from alalek:perf_stability_check
History
Updated by Kevin Hughes over 11 years ago
oh fyi here is a link to the tutorial
http://kevinhughes.ca/tutorials/opencv-install-on-windows-with-codeblocks-and-mingw/
Updated by Dmitry Retinskiy over 11 years ago
Hi Kevin,
thanks for your interest to making OpenCV better and the work you do in scope of OpenCV related tutorials in your blog.
(By the way, have you considered adding some of them to the official set of OpenCV tutorials? Just in case if you are interested, here is the link with instructions).
Regarding the issue you have described here: it, actually, doesn't look like a bug in OpenCV (please correct me if I am wrong), it looks more like a configuration/environment problem somehow connected with MinGW.
In this case I'd suggest to open a question at http://answers.opencv.org and check if our community could help.
- Priority changed from High to Normal
- Assignee deleted (
Roman Donchenko) - Difficulty deleted (
Easy) - Estimated time deleted (
0.50)
Updated by Kevin Hughes over 11 years ago
Hey! sorry I was expecting to get an email when this issue was updated but that didn't happen for some reason.
I actually don't have much time to work on this right now (I just started a new job). I updated the tutorial on my site to include directions for how to build the binaries yourself and overwriting the ones distributed with opencv and this seems to be working for people.
You're right its not a bug in OpenCV, I am more just curious about what could be different between the mingw binaries that are distributed with a release and the ones I built locally. Can you provide the details about how the release binaries are built?
Cheers
Updated by Ivan Korolev over 11 years ago
Can you provide the details about how the release binaries are built?
Roman, could you please help?
- Assignee set to Roman Donchenko
Updated by Philippe FOUBERT over 11 years ago
I am also using OpenCV with MinGW (but the 64 bits version). I always build the binaries myself (to choose its content, to adjust the build options to my hardware and optionally to be able to modifiy it).
If i want to be able to install my application using OpenCV on an other computer, i have to install it with at least some MinGW libraries:- libgcc_s_seh-1.dll
- libstdc++-6.dll
- libwinpthread-1.dll
and of course OpenCV additional third party libraries (opencv_ffmpeg300_64.dll,...)
I have not tested the pre-built windows binaries but i think you should check the availabilty of these MinGW libraries.
Regards, Philippe.
Updated by Kevin Hughes over 11 years ago
The binaries are there thats not the issue, the error would be different if it were a missing dll, this is more like a not fully compatible dll
Updated by Alexander Smorkalov over 11 years ago
- Target version changed from 2.4.7 to 2.4.8
- Affected version changed from 2.4.6 (latest release) to 2.4.0 - 2.4.6
Updated by Amro _ about 11 years ago
I think there is a confusion here; MinGW can refer to the original project (MinGW.org) which can only compile for 32-bit targets. There is also the "fork" project MinGW-W64 which can compile for both 32-bit and 64-bit targets.
To make things worse, MinGW-w64 provides different variations for the same architecture. One could choose native Win32 threads vs. posix-threads implementations. Also one must choose the C++ exception model: dwarf, sljl, or SEH. mingwbuilds provide precompiled GCC binaries for all these configurations...
http://sourceforge.net/projects/mingw-w64/files/Toolchains targetting Win32/Personal Builds/mingw-builds/
http://sourceforge.net/projects/mingw-w64/files/Toolchains targetting Win64/Personal Builds/mingw-builds/
As a result, some of the binaries produced have additional dependencies such as:
- libstdc++-6.dll
- libwinpthread-1.dll
- libgcc_s_seh-1.dll
- libgcc_s_dw2-1.dll
- libgcc_s_sjlj-1.dll
- ..
Now correct me if I'm wrong, but I'm not sure one can mix shared libraries built with different configurations...
Updated by Amro _ about 11 years ago
This means you will either have to: 1) provide precompiled OpenCV binaries for all these variations (x86/x64, win32-threads/pthreads, dwarf/sljl/seh exceptions) for a total of eight variations. Since this will increase the size of the downloaded file considerably, I would prefer to split it. 2) provide only one used by the person who build the package and require everyone to use the same configuration, or 3) simply omit them from the package and let users build their own using the MinGW version they have.
By the way, why don't you you guys split the package into x86 and x64 files at the very least?
Updated by Alexander Smorkalov about 11 years ago
- Target version changed from 2.4.8 to 2.4.9
Updated by Kevin Hughes about 11 years ago
I think Amro is right this is what I suspected the issue was. One of the other opencv dev's who is in charge of the release builds told me via email that in the future there will only be pre-compiled binaries for msvc - this is probably due to wanting to avoid all the possible mingw configurations. If that is the case then this can be closed otherwise if you're going to continue releasing mingw binaries you need to provide the details of the mingw configuration so that we can use the same version and avoid compiling opencv.
- % Done changed from 0 to 30
Updated by Kevin Hughes about 11 years ago
- Status changed from Open to Cancelled
Updated by Philippe Rubbers almost 11 years ago
May I please request that mingw binaries be included in future builds.
I am out of my depth in trying to build binaries myself, and instructions have always been confusing.
I have been stuck at opencv 2.4.5 which came with binaries.
If the same build settings can be used with 2.4.9, it would be great.
Uncompressed, the mingw binaries were previously 45Meg (not 350Meg as per vc11)