[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Mingw-cross-env-list] Problems with exceptions and threads, run tim
Re: [Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue
Fri, 22 Apr 2011 15:17:41 +0200
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:184.108.40.206) Gecko/20110402 Icedove/3.1.9
Kay Hayen schrieb:
+ --disable-sjlj-exceptions \
Previously I read that DW2 exceptions were now the default. Was this
reverted somehow? And why?
I fully agree to include this line, as SJLJ exceptions are
not meant to be enabled at all in mingw-cross-env. I just
committed that improvement in your name. Thanks!
Thanks a lot, appreciated.
+ # 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/'
I'm not sure about those lines.
In no way consider them a proposed patch. :-) Other than that, it's what
I do to get a MinGW that links against the msvcr90.dll, doing it
properly likely means to work with the spec file logic.
> To my understanding, GCC should
not produce anything that depends on the msvcr90 runtime, so I don't
know how you got that double-dependency on msvcrt+msvcr90 in the
To me, it seems to be more "right" to hunt down this msvcr90
dependency and to ensure that only msvcrt is used. However, feel
free to complain if I'm talking nonsense here.
My problem is that I want to use the Python26.dll, Python27.dll as from
python.org binaries. They build using the MS runtime. So I get to load
it and then I get errors.
I don't see how two run times can coexist without troubles. A solution
to this would be a cross-compiled CPython. But to my understanding, the
msvcrt.dll has bugs that were never fixed. and would show themselves
with a Python that uses too old run times.
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.
I'm not sure whether GCC is meant to be (runtime-)configurable in
that regard. Also, to my understanding it should not matter if a DLL
uses a different C runtime than the calling application (Python).
(However, C++ is a totally different situation. Here, not only
the runtime but also the compiler and compiler version have to
be the same. This is why foreign language binding are usually
based on C rather than on C++ interfaces.)
I am using generated C++ though, so to me it is an issue.
Regarding mingw-cross-env, I'd accept a patch that permanently
switches the used runtime from msvcrt to msvcr90, as this should
still support all Windows versions currently supported by MS.
To do it permanently seems easy enough. But I thought that there is no
msvcr90.dll on a fresh machine, is there? At least for my wine install I
don't think there will be one. So I am assuming it should be possible to
switch in any case. Also there appear to be many more variants that one
might be stuck with.
However, I'd first like to see a discussion on MinGW-Users about
that topic, as the MinGW experts are there, not here.
To all other mingw-cross-env users: Please complain if there
are reasons not to do that!
I will wait before raising it on MinGW users for feedback here, so it's
not an overlap.