This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lkcl
Recipients lkcl
Date 2009-01-15.21:20:39
SpamBayes Score 0.096596405
Marked as misclassified No
Message-id <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
In-reply-to
Content
this patch uses work from #3871 to get a build of python for win32
by running msys under Wine, the windows emulator, on linux.
no proprietary operating system or proprietary software was used.

/bin/sh.exe is so xxxxing unbelievably slow on msys under wine
(each sh.exe takes two seconds to start up, loads 240 fonts
and 40 libraries) that running configure was completely intolerable.

consequently, given that PC/config.h is perfectly useable on nt,
this patch totally bypasses the majority of autoconf tests, and
thus cuts the configure time down from three hours to (only!)
fifteen minutes.

configure must be run as:
   ./configure --prefix/python25 --enable-win32build=yes  \
               --enable=shared=yes

there is an additional bug in msys /bin/sh which stops python.exe
from executing scripts that are handed to it on the command-line.
scripts that are fed as standard-input are absolutely fine
(even the same script).  running the same script from python.exe
from wineconsole cmd prompt is _also_ fine.

as a result, the build process terminates at:
   ./python.exe -E setup.py build

to complete the build, "wineconsole cmd" must be run, cd $(BUILDDIR)
and then run the commands manually:
   ./python.exe -E setup.py build
   ./python.exe -E setup.py install
then, back in the borked /bin/sh.exe, make install can be run.

stunningly, this does actually work: python.exe is build,
libpython2.5.dll and libpython2.5.dll.a are built... amazing.

other necessary workarounds:

* gcc -shared .... --out-implib=libpython2.5.dll.a .... etc fails
  spectacularly to create both the .a implib _and_ the .dll.
  consequently, it was necessary to split these up and use dlltool
  to create the dll, implib and .def file etc. etc.

* ar and ranlib on msys, versions 2.16, 2.17 _and_ 2.19 of binutils
  are borked.  2.16 and 2.17 throw an exception; 2.19 segfaults.
  consequently, building of $LIBRARY had to be terminated with
  prejudice.  --enable-shared=no will fail miserably.

regarding testing: it's all a bit... odd.

* ctypes tests cause segfaults!  the S8H one manages a segfault
  all on its own, but there are other tests that cause corruption
  that only shows up later... euurgh.

* builtin test_open fails due to putting \r\n instead of \n in the file

* test_file.py gets a sharing violation

* test_str gets a great one!

   test_str^M
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   fixme:msvcrt:MSVCRT__sopen : pmode 0x01b6 ignored
   err:seh:setup_exception_record stack overflow 872 bytes in thread
001e eip 7bc3b1dc esp 00410fc8 stack 0x410000-0x411000-0x610000

   yup.... test_floatformatting.

   ahh, this is gooood :)


overall it's a damn good start - i'm dead impressed with
wine and msys in that they exist at all.

compiling and testing python under wine + msys should help
test and improve both those projects, and both this patch
and #3871 will help get python off of its dependence on
proprietary software.
History
Date User Action Args
2009-01-15 21:21:04lkclsetrecipients: + lkcl
2009-01-15 21:21:04lkclsetmessageid: <1232054464.28.0.565807306717.issue4954@psf.upfronthosting.co.za>
2009-01-15 21:21:02lkcllinkissue4954 messages
2009-01-15 21:20:54lkclcreate