[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Mingw-cross-env-list] Problems with exceptions and threads, run time li

From: Kay Hayen
Subject: [Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue
Date: Mon, 04 Apr 2011 22:42:32 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110303 Icedove/3.0.11


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,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]