[Top][All Lists]

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

Re: [Mingw-cross-env-list] Problems with exceptions and threads, run tim

From: Kay Hayen
Subject: Re: [Mingw-cross-env-list] Problems with exceptions and threads, run time library selection issue
Date: Fri, 22 Apr 2011 15:17:41 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110402 Icedove/3.1.9

Hello Volker,

Kay Hayen schrieb:
          --disable-shared \
+        --disable-sjlj-exceptions \
          --without-x \
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
first place.

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.

Kay Hayen

reply via email to

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