[Python-Dev] MinGW And The other Py2.4 issue

[Paul Moore]

On Mon, 13 Dec 2004 23:17:51 +0100, Martin v. Löwis <martin at v.loewis.de> wrote:
> I forgot the details of your analysis, but I think you are right.
> However, I would feel more comfortable if only a single CRT was used
> from an extension module.

Agreed. But to some extent I'm equally uncomfortable with the idea
that the mingw developers added support for -lmsvcr71 and botched it
badly enough for things like this not to work :-)

> As for creating a case that crashes if you mix CRTs: Just try
> PyRun_SimpleFile in the extension, with a file that you fopen'ed
> in the extension. Satisfy this fopen from, say, msvcrt.dll, and
> load the extension into Python 2.4.

Sorry, I wasn't specific enough. Certainly, if you create a FILE* from
one CRT, then pass it to another CRT, this will fail. But my point is,
if your extension uses fopen() then the link command generated by
distutils will ensure that the symbol is satisfied from msvcr71.dll.
So your scenario cannot occur.

The only symbols which can be satisfied from msvcrt in a
mingw-compiled extension (assuming that distutils is used, or the
-lmsvcr71 flag is otherwise added) are those referenced in the mingw
startup code, but not in user code. As the startup code will never
reference Python APIs, CRT data should never be shared between
incompatible CRTs.

Your point about atexit (from another email) may be an issue. However,
again we have the fact that user C code is *always* satisfied from
msvcr71, so any exit handlers added in C or Python will be registered
with the msvcr71 CRT, and so, as the main python.exe uses msvcr71,
will be executed. I don't see any signs that the mingw runtime for a
DLL uses atexit (this by experiment, I haven't time at the moment to
review the mingw sources) and so I don't believe that the startup code
has issues here, either.

Thanks for your comments. Your support for the viability of building
extensions using mingw is important to me, so if you still have any
concerns, let me know and I will do my best to address them.

Paul.