[Python-Dev] SUCCESS! 2.4 extensions w/mingw (was Re: Switching to VC.NET 2003)

Phillip J. Eby pje at telecommunity.com
Sun Jan 4 11:00:45 EST 2004


At 12:42 PM 1/4/04 +0100, Martin v. Loewis wrote:
>Phillip J. Eby wrote:
>
>>It looks like everything's cool for building 2.4 extensions with mingw.
>
>Very good! You should still double-check what DLLs your .pyds depend
>on; this is best done with depends.exe (if you have that).

Nope.  Apparently that's part of the Visual C toolkit.


>  GNU objdump
>may also be able to do that.

Also nope.  But I googled and found there's a 'cygcheck' that does 
basically the same thing.  It shows that the .pyd's are still linking 
w/msvcrt.dll.  :(  I have no idea how to stop it, either.

I don't know what effects this might have, although clearly it hasn't 
stopped the extensions I built from working.  But none of the extensions I 
tried do anything with e.g. file descriptors, raw memory allocation, or 
floating point math, and I'd assume that those are the areas most likely to 
have issues.



>>It'd be nice to throw in the libs/libpython24.a file, too, but it's big 
>>(603K) and I guess everybody who's been using mingw to this point either 
>>knows the procedure for making it by heart, or at least has a bookmark to 
>>one of the webpages that explains how to do it.
>
>It would also require to have a certain amount of cygwin on the
>packaging machine, right?
>
>If the procedure could be modified to only use tools available on the
>target machine, I could look into generating that library on
>installation time. Alternatively, distutils could be modified to
>generate it on first use.

Probably distutils would be the place to do it, since you may install 
Python long before you realize you'd like to make C extensions with 
mingw32.  So, the needed tools (pexports.exe and dlltool.exe) wouldn't be 
available at install time.

Doing it at first use has only the issue that the user would have to have 
rights to write to the Python24/libs directory, even if they're not 
planning to install anything there.  So, distutils would have to build the 
library in the local build/ directory if it couldn't write to the libs 
directory.

Hm.  Really, it begins to sound as though there should either be a separate 
distutils command to build the library, or just a script you can run to 
build and/or install the library.  I'll consider writing something -- at 
least a doc patch, if not a script -- for 2.4.




More information about the Python-Dev mailing list