[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Mingw-cross-env-list] Problems with exceptions and threads, run time li
[Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue
Mon, 04 Apr 2011 22:42:32 +0200
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:220.127.116.11) 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
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
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
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
cd '$(1).build' && '$(1)/configure' \
- --enable-languages='c,c++,objc,fortran' \
+ --enable-languages='c,c++' \
+ --disable-sjlj-exceptions \
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
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,
- [Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue,
Kay Hayen <=