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

[Luke Kenneth Casson Leighton]

On Thu, Jan 22, 2009 at 6:43 PM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
>>> 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.

 ah right - sorry to not quite fully understand.

> Do you have a DLL that contains
> all of Python/*.o and Objects/*.o?

 yes.

>>> 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?

 ... *thinks*... sorry, you're right.

 it's the way that dlltool is used on cygwin.

 dlltool on cygwin and gcc on cygwin create files with the following
equivalence:

 python25.lib on msvc <---> libpython2.5.dll.a on cygwin and mingw32
 python2.5.dll on msvc <--> libpython2.5.dll on cygwin and mingw32

>> 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.

 there are at least three [mingw] already.

> 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).

there are already no less than _four_ mingw ports of python, of varying degrees.

* http://jove.prohosting.com/iwave/ipython/pyMinGW.html
* http://sebsauvage.net/python/mingw.html
* http://python-mingw.donbennett.org/
* roumen's cross-compile+native port
* the port i'm working on - extending roumen's native mingw compile

one dates back to... python 2.2 i didn't include that one.  another is
python2.4.  don's work is a cygwin cross-compile (note NOT a "compile
of python for cygwin such that you need CYGWIN.DLL to run python"),
so, using cygwin under win32 to cross-compile a native python.exe.
smart, that.  roumen then worked on that further, to make it compile
under mingw / msys, not cygwin.  and i'm working on taking windows
_completely_ out of the loop, by getting python.exe to both compile
_and_ run under wine, with the added benefit that if you _did_ happen
to want to compile (or run) under either native windows or both, you
can.

l.