[Distutils] Mingw Python 2.4

AGiss public-dstml at giss.ath.cx
Sun Apr 3 09:47:13 CEST 2005


I tried to compile some extensions under Windows/Python 
2.4 using distutils and mingw as compiler (not MS-VC++).

(You can just jump to conclusion at the bottom if you like, 
but be aware that I don't really master the subject, so 
I may have missed something. If you thing my conclusions
doesn't make sense, please read what happens to me.)

(Official Python2.4, the one that use msvcr71.dll)

I got some strange results like "the softwares I wrote using this 
extension crashed randomly". I first thought that extension 
(that I didn't wrote) was crappy.

When the second extension crashed too, I tried to understand 
a bit more.

The crash is more or less random, (but when it doesn't crash, 
everything works as expected even the code in the extension) 
and it crash with an OS error 0xc0000008 (it look like it's 
an internal windows error which mean there is something really
nasty with the memory.

So the .pyd was linked to msvcrt.dll and to msvcr71.dll.
As it looks fishy, I tried to reinstall python 2.3 for 
windows that doesn't use msvcr71.dll but msvcrt.dll).

I wasn't able to reproduce the crash.

Then I realize the extension provided a way to build the same 
.pyd (but I wasn't able to generate an installer for the 
extension, that's why I didn't use it).

So I look at the .pyd generated for python 2.4 with the 
makefile, and... it was only linked to msvcrt.dll. 
So I trie to use it instead and... it works !!!

I tried to recompile everything from scratch using distutils 
because it may just be because a "bad neutrino who hit my 
motherboard at the worst moment", but the bug was still here.

So I tried to figure out what was the difference between the 
command lines used by the makefile and distutils. And... the 
obvious difference was that distutils used a -lmsvcr71. 


I looked at distutils code source, and quickly found the line 
that makes mingw use msvcr71. IV just changed it.

I rebuild all, and... It just worked well. (and of course, the 
.pyd was just linked to msvcrt and not msvcr71 anymore)


Sooooooooooooooooo here are my conclusions :

Something isn't right when compiling with mingw using msvcr71.
(command line option ? problem with mingw ? problem with 
msvcr71 ? mingw just need some more configuration to works 
with msvcr71 ? I don't really know)

It *look* like compilling extension using msvcrt instad of 
msvcr71, even if python use msvcr71 is safer that letting
mingw using msvcr71.

So I propose to remove the lines from 330 to 332 on the file
cygwinccompiler.py (revision 1.29, the actual one, and the 
one used with python 2.4) 

The code is specific for Windows/Mingw/(python compiled with msvc 7.1)
so there shouldn't be any side effect.

Perahps it's wise to do the same for the line that add "msvcr70" 
(but I don't know).

Perhaps it's wise to do the same on lines 130-135 (The same code, 
but for cygwin's internal gcc, and not mingw's gcc), but I don't 
know if cygwin suffer for the same problems.

More information about the Distutils-SIG mailing list