[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 19:00:04 +0200
Kay Hayen schrieb:
> >(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.
Oh, in that case there is another important issue you should
be aware of: If you are really using C++ for the interface
(that is, if you are _not_ just using C++ internally behind
a C interface),
then this all will only work if the Python DLLs are built
with a MinGW compiler and not, say, Visual Studio. As
already mentioned, in that case not only the compiler but
also the compiler version would have to match. No offense
inteded, but I really hope that this is not what the Python
guys are really doing. I once wrote a Python extension and
I was happily able to press everything through a C interface. 
> >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?
To my knowledge, it is available at least on Vista an Windows 7.
I'm not sure about XP.
> At least for my wine install I don't think there will be one.
Indeed, that's an issue. I was hoping that Wine would provide
some kind of msvcr90-compliant support, but I never actually
checked this. :-(
> 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.
The problem with multiple variants is that we can't test
them all. Our resources are barely enough to "check" the one
configuration, at least that it compiles, links and that some
projects report success who are actially using mingw-cross-env.
If error reports would become dependent on the used runtime,
that would be simply too much for us to handle reasonably.
Also, each variant would receive even less "real-world" testing
than it already does.
Another argument: There is no such "runtime-switch" in GCC/MinGW,
and they seem to have a reason for that. Whatever that reason
might be, I'm pretty sure this reason also applies to our
As always, feel free to prove that I'm wrong here.
For now, I recommend to keep this as a local change on
your side. However, feel free to come up with a permanent
change once you got some positive feedback from some MinGW
> >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.
Okay, feel free to do so. :-)
 Slightly off-topic, but if you are interested, the project is: