[Wine] compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now
Luke Kenneth Casson Leighton
luke.leighton at googlemail.com
Tue Jan 20 07:02:25 CST 2009
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
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
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.
More information about the wine-users