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

[Kay Hayen]

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!
>
> http://hg.savannah.gnu.org/hgweb/mingw-cross-env/rev/9e757634e635

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.

Yours,
Kay Hayen