[RFC] Crash sourcing Python script on Windows

[Kai Tietz]

2011/9/29 Eli Zaretskii <eliz@gnu.org>:
>> Date: Thu, 29 Sep 2011 10:38:51 +0200
>> From: Kai Tietz <ktietz70@googlemail.com>
>> Cc: Joel Brobecker <brobecker@adacore.com>, maillist-gdbpatches@barfooze.de,
>>       gdb-patches@sourceware.org
>>
>> The issue here is not the definition of the FILE type itself in this
>> case.  The problem is that python (if built with VC) uses different
>> runtime-version (msvcr100.dll or lower), but mingw uses by well know
>> reasons the msvcrt.dll.  So by loading this python-DLL into a
>> mingw-built executable, we have two different runtimes at the same
>> time.
>
> Thanks, this makes sense.
>
> What are the reasons that we build GDB against msvcrt.dll?

The issue is a legal thing.  The newer runtimes mvcrXX.dlls aren't
part of the OS itself.  The msvcrt.dll is present on all WIndows OSes
(well always in a different version).  So we can assume that everybody
has a working msvcrt.dll present on his OS.  Due the fact that
msvcrXX.dll aren't part of runtime, you would need to distribute those
DLLs to end-user, which would be (INAL) a violation of EULA as far as
I understood it, if you haven't a VC license for it.

>> By the way, the same issue can lead also for different C-runtime
>> functions pretty funny results.
>
> Exactly.  If we have such an incompatibility once python's DLL is
> loaded, it can lead to similar crashes elsewhere.  So, unless we can
> find a way of linking against msvcrNNN.dll or build our own Python
> with MinGW, it sounds like using Python on Windows is unsafe?

Well, not necessarily.  You need just to take care that file-I/O and
memory-functions are used only in context of one of those libraries
and no exchange of those pointers/file-handles (on C-level, not
OS-level) happens.  For example Java-VM-Runtime works that way pretty
nice with msvcrt, as long as you take care not to do here those
failures.

Regards,
Kai