compiling python2.5 (msys+mingw+wine) - giving up using msvcr80 assemblies for now

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



folks, hi,
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?

l.


[Index of Archives]     [Gimp for Windows]     [Red Hat]     [Samba]     [Yosemite Camping]     [Graphics Cards]     [Wine Home]

  Powered by Linux