[Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue

[Kay Hayen]

Hello,

I have recently had troubles with cross-compiling the Nuitka generated 
source code to Windows with mingw-cross-env, first with the 4.5 based 
stable release (2.19) and then with the 4.6.0 based release inside hg.

I have reason to believe that it's maybe ming-cross-env at fault, at 
least partially.

The symptom with stable was that according to my traces, raising an 
exception in a thread gave me a segfault (under wine). At the same time 
some body else used the same code with MinGW on Windows native without a 
problem.

As this was related to exceptions, I chose to go 
"--enable-sljl-exceptions" and voila, the problem changed, the exception 
got raised, but caught by the _other_ thread, which obviously was the 
wrong behaviour.

Some back and forth later, we eliminated wine as the culprit, because my 
cross compiled binary, this is with unstable (hg, 4.6.0), worked no 
better on native Windows then it did with wine.

Then in my quest to eliminate the use of both "msvcrt.dll" and 
"msvcr90.dll" with a manifest, rc, and so on, I enabled shared linking 
to libgcc and the libstdc++6, which surpringly turned out to require a 
DLL with sjlj in the name.

Now my bug does away if I do these things:

hg diff src/gcc.mk
diff -r bf7d50fab8f2 src/gcc.mk
--- a/src/gcc.mk        Sat Apr 02 11:16:57 2011 +0200
+++ b/src/gcc.mk        Mon Apr 04 22:31:12 2011 +0200
@@ -29,18 +29,27 @@
     cd '$(1)' && $(call UNPACK_PKG_ARCHIVE,gcc-mpfr)
     mv '$(1)/$(gcc-mpfr_SUBDIR)' '$(1)/mpfr'

+    # Patch to not use msvcrt.dll, but msvcr90.dll
+    sed -i $(1)/gcc/config/i386/t-mingw-w32 -e 's/msvcrt/msvcr90/'
+    sed -i $(1)/gcc/config/i386/t-mingw-w32 -e 's/moldname/moldname90/'
+    sed -i $(1)/gcc/config/i386/t-mingw32 -e 's/msvcrt/msvcr90/'
+    sed -i $(1)/gcc/config/i386/t-mingw32 -e 's/moldname/moldname90/'
+    sed -i $(1)/gcc/config/i386/mingw32.h -e 's/msvcrt/msvcr90/'
+    sed -i $(1)/gcc/config/i386/mingw32.h -e 's/moldname/moldname90/'
+
     # build GCC and support libraries
     mkdir '$(1).build'
     cd    '$(1).build' && '$(1)/configure' \
         --target='$(TARGET)' \
         --prefix='$(PREFIX)' \
-        --enable-languages='c,c++,objc,fortran' \
+        --enable-languages='c,c++' \
         --enable-version-specific-runtime-libs \
         --with-gcc \
         --with-gnu-ld \
         --with-gnu-as \
         --disable-nls \
         --disable-shared \
+        --disable-sjlj-exceptions \
         --without-x \
         --disable-win32-registry \
         --enable-threads=win32 \

-------------------

The sed commands at the top are to convince the MinGW that I really, 
really want it to use msvcr90.dll for the run time. As doing some spec 
file changes didn't work to change the c++ run time, I guess I need that 
patch to mingw32.h, right?

Then notice that I had to add "--disable-sjlj-exceptions" to get rid of 
sjlj exceptions.

Now obviously I am confused:

4.5.0 + DW2 exceptions -> segfault, likely due to duplicate run times, 
or due to some thread problems with 4.5 ?

4.5.0 + SLJL exceptions -> wrong thread catches.

4.6.0 + SJLJ exceptions + one runtime -> wrong thread catches

4.6.0 + DW2 exceptions + one runtime -> works

------------

Previously I read that DW2 exceptions were now the default. Was this 
reverted somehow? And why?

And what are the chances of making the runtime to be used for created 
binaries configurable? For compiling Python extensions or Python 
embedding programs, there is really no other way than to use that 
specific run time I believe.

Interestingly the different run times never were a problem on the native 
Windows, and probably aren't part of the deal at all, although I sort of 
doubt it, the C++ runtime can hardly be thought of not being a part of 
C++ exception handling.

Thanks in advance,
Kay