Version 4.3.2-12 of EPEL's version of the moingw32 cross-compiler do not support cross-DLL exceptions.
I've attached the gcc bug report below. This make running a non-trivial C++ program impossible an renders the mingw32 toolchain unusable for real-world C++ programs.
The mingw-w64 toolchain has solved this problem by supplying a shared libgcc, hopefully the mingw32 toolchain will follow this approach in the near future.
Please keep on your tremendous work on providing the ming32 toolchain in the EPEL.
can you give us a little bit more detail!?
anyway there is _not_ any kind of standard c++ exception on windows each compiler has it's own exception handling. so it you use gcc for every dll what you use than it'll work. more detail here:
Created attachment 334400 [details]
A testcaes, which trowas an exception across a DLL boundary.
This testcase throw an exception from iside a DLL an catches it in the main program. The generated 64 bit executables of mingw-w64 are working as expected.
The 32bit executables fail with
terminate called after throwing an instance of 'MyException'
BTW, I'm only using C++ programs which are all compiled by the same version of gcc.
Thanks for the test case - it's definitely good to have a way to test whether what we're
doing is correct.
Do you know about the (to me) "mysterious" DLL that gcc 4.4 installs?
Does it help, hinder or is it irrelevant?
According to my experience with mingw-w64, which is gcc-4.4 based, this DLL is referenced by all my C++ DLLs compiled with mingw-w64 and to my knowledge this DLL is the key to cross-DLL exception handling. (contains some _Unwind_* export functions...)
Since I'm not a specialist in this area you might ask the mingw-w64 people for further explanations, since these guys seem to be the driving force behind the gcc-4.4/mingw integration.
> Do you know about the (to me) "mysterious" DLL that gcc 4.4 installs?
> Does it help, hinder or is it irrelevant?
That's a shared libgcc (plus, it's using sjlj, not DWARF2 which currently doesn't work across DLLs unless this was solved somehow recently), so it should fix the issue.
Note that the bug report was about 4.3.2, not 4.4, so it's quite possible 4.4 fixes it.
One thing to check is whether static or shared libgcc is the default. If it's static, you'll also need to compile both the DLL and the executable with -shared-libgcc to make it work.
AFAIK this problem is one of the reasons (if not _the_ reason) why the MinGW project is sticking with gcc 3.4.5 instead of upgrading to the 4.x serie.
(In reply to comment #6)
> AFAIK this problem is one of the reasons (if not _the_ reason) why the MinGW
> project is sticking with gcc 3.4.5 instead of upgrading to the 4.x serie.
It's Fedora policy to follow upstream (and fix upstream if it's
I'm currently trying the gcc-4.4 based mingw-w32 toolchain from the mingw-w64 project. As with their 64bit toolchain they solved the cross-DLL exception problem there by introducing libgcc_s_sjlj-1.dll.
However, gcc-4.4 seems to introduce some new instabilities I'm currently trying to trace. So I think everybody would be happy if the fedora mingw team and the mingw-w64 people could join their forces to make gcc-4.4+mingw a success story ;-)
(In reply to comment #7)
> It's Fedora policy to follow upstream (and fix upstream if it's
My remark was not intended to be a proposal to downgrade, just a statement about why this was a more or less expected problem. If we can fix the issue, good, it will show a real benefit of Fedora-MinGW effort.
However, given how much time this problem is around, I wonder if it's that easy to fix... Do we have resident (@redhat) experts in the field to ask?
It is already fixed, see comment #8. It will be fixed in Fedora when the packages will be upgraded to 4.4. (In Rawhide, that already happened.)
Please note, that the mingw-w64 people have now fixed a nasty stability problem in their mingw-w64 distribution (not affecting 32 bit binaries), so gcc-4.4 for Windows x8 and x64 seems to be quite stable now ;-)
Note upstream at mingw has released some 12/13 patches for gcc 4.4.0 in June, and also recommend dwarf2 instead of sjlj...
I believe this bug was fixed in an upstream:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34684, so let me change the flag as:CLOSED/ERRATA , feel free to reopen this bug if u still experiencing this problem.
Fedora Bugzappers volunteer triage team