On Thu, Jan 22, 2009 at 6:43 PM, "Martin v. Löwis" <mar...@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. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
