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

["Martin v. Löwis"]

>> I can't comment on that, because I don't know what your port does.
>> Does it not produce a .dll containing the majority of Python?
> 
>  no, it contains the minimal necessary amount of python modules,
> exactly like when python is built using cygwin.  actualy, there's a
> few modules that _have_ to be included.

That's actually not my question. Do you have a DLL that contains
all of Python/*.o and Objects/*.o?

>> And is that not called python25.dll?
> 
>  no, it's called libpython2.5.dll.a, just like when python is built
> using cygwin.  the configure scripts, thanks to the cygwin build,
> already end up copying that to libpython2.5.dll.
> 
> _not_ python25.dll

I'm giving up for now. I don't quite understand why the file gets
first called libpython2.5.dll.a, and then renamed to libpython2.5.dll.
Could it be perhaps that the .a file is an import library, and actually
different from the .dll file?

> p.s. there's nothing to stop you adding every single module and then
> renaming the resultant blob to libpython25.dll - i just haven't been
> given, or found, a good reason to do so yet.

That doesn't really matter, I guess. An extension module build by your
port will either fail to load into the regular Python (if
libpython2.5.dll is not found), or load and then crash (because it uses
a different copy of the Python runtime). Likewise vice versa.

If this port ever takes off, we get another binary-incompatible Python
version. I hope that users will understand that it is disjoint from
the python.org version (as they seem to understand fine for the
Cygwin build, which already picks up its extension modules also from
a disjoint location, which helps to keep the two separate).

Regards,
Martin