Re: [RFC] Crash sourcing Python script on Windows

[Kai Tietz <ktietz70@googlemail.com>]

2011/9/29 Eli Zaretskii <eliz@gnu.org>:
>> Date: Wed, 28 Sep 2011 21:06:34 -0700
>> From: Joel Brobecker <brobecker@adacore.com>
>> Cc: gdb-patches@sourceware.org
>>
>> It could be something simpler than that. Python was built on one
>> system, using an unknown build environment. when then use that
>> library to link it against some code on a version of Windows that
>> is most likely different, with a compiler that is also most likely
>> different. If each compiler used a libc where the definition of
>> that type is different, then we have an incompatibility.
>
> That's true, but just looking at the definitions of the FILE object in
> both MS and MinGW headers, I can't see any differences.  Which is
> quite expected: if it were not so, MinGW programs couldn't call APIs
> that accept FILE objects, like `fopen', since the implementation of
> `fopen' is in the Microsoft runtime DLLs, which was compiled by the
> Microsoft compiler, the same one used to build Python DLLs for
> Windows.

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.  So FILE * of one library not necessarily operates in the other
library.  By the way, the same issue can lead also for different
C-runtime functions pretty funny results.

Regards,
Kai