[Python-Dev] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now (original) (raw)

Terry Reedy tjreedy at udel.edu
Wed Jan 21 01:04:06 CET 2009

Luke Kenneth Casson Leighton wrote:

this is a fairly important issue for python development interoperability - martin mentioned that releases of mingw-compiled python, if done with a non-interoperable version of msvcrt, would cause much mayhem. well, compiling python on mingw with msvcr80 can be done; using it can also be a simple matter of creating a python.exe.manifest file, but i can't actually do any testing because it doesn't work under wine. so, pending any further advice and guidance from anyone which allows me to successfully proceed, i'm not going to continue to compile - or release - python2.5 or python2.6 builds (when i get round to that) using msvcr80 or msvcr9X. one issue in favour of this decision is that the DLL that's produced by the autoconf build process is "libpython2.5.dll.a" - not "python2.5.dll". it has a different name. it should be abundantly clear to users and developers that "if name equals libpython2.5.dll.a then duh build equals different". additionally, the setup.py distutils all goes swimmingly well and lovely - using libpython2.5.dll.a. the only issue which is going to throw a spanner in the works is that people who download win32-built precompiled c-based modules are going to find that hey, "it don't work!" and the answer will have to be "go get a version of that module, compiled with mingw, not MSVC".

of course - if python for win32 ENTIRELY DROPPED msvc as a development platform, and went for an entirely free software development toolchain, then this problem goes away. thoughts, anyone?

As I understand the above, you listed or implied 3 paths other than you completely giving up, which you are not ready to do yet.

  1. You release non-interoperable binary, with a modified name to alleviate, but not prevent confusion.
  2. You get some sort of help from someone to release an interoperable binary.
  3. The devs drop msvc (wink missing ;-).

Not surprisingly to me, people on pydev followed herring #3 to explain why not. If you want responses to path 2, a post leaving out 3 and giving more detail might be more successful. All I could do is unzip stuff into a temp directory and run the test suite on my XP mechine.

Terry Jan Reedy

More information about the Python-Dev mailing list