classification
Title: Cross building python for mingw32
Type: Stage:
Components: Build Versions: Python 2.3
process
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: Nosy List: loewis, yxcv
Priority: normal Keywords: patch

Created on 2003-11-13 14:31 by yxcv, last changed 2006-11-11 13:24 by loewis. This issue is now closed.

Files
File name Uploaded Description Edit
python-2.3.2-mingw32-cross.patch yxcv, 2003-11-13 14:31 patch to cross compile python-2.3.2 with the mingw32 gcc
xbuild-py.sh yxcv, 2003-11-13 14:32 xbuild-py.sh
Messages (2)
msg44879 - (view) Author: Andreas Ames (yxcv) Date: 2003-11-13 14:31
At first:  I can't follow the submission guidelines
because I'm sitting behind a firewall and therefore
can't access external cvs repositories.  So this patch
applies to the release Python-2.3.2 source tarball. 
Nevertheless I hope, it might be useful for others.

The attached patch allows to cross-compile python from
linux (and probably cygwin) to mingw32.

Some remarks:

1) Python's stock configure.in has no support for
cross-compilation.  Although I've tried to limit the
changes to the minimum necessary for a mingw32 build,
I'm certain that the changes break some native build
anywhere (I've not even tested a single native build
seriously).
Some (remaining) problems are:
- the use of AC_TRY_RUN
- looking for /dev/... files at configuration time
- the use of 'uname' (instead of configure's --build
commandline switch)
- ...

2) I'm proposing to use scons for the build of the core
extensions for cross-builds (and have included minimal
sconstruct/sconscript files) because I do not dare to
change distutils to support cross-compilation as I have
only finite time resources and I would certainly break
all kinds of stock functionality (if I could do it at
all).  Although scons doesn't support cross-builds
either, it at least doesn't prevent them.  This way, it
seemed easier to me, YMMV.

3) There are quite a few warnings when compiling.  I've
only halfheartedly tried to solve a few of them.  Even
when I use vc6 with the warning level pushed to 4
(which should be more compareable to -Wall), many of
them don't show up.  OTOH, vc6 seems to be more sloppy
anyway. Maybe others can help?

4) I have not yet built core extensions with more
complex external dependencies and darwin-specific
modules (bsddb, tkinter etc., look at
Modules/sconscript for a complete (?) list)

5)  'regrtest.py -l -uall' behaves the same for the
mingw32-build as for the vc6-build, iff I don't let gcc
optimize the code.  At least with the default -O3 and
also with -O2, test_import.py crashes on the reload
test, because the magic number returned by the
marshaller is different from the expected 'pyc_magic'
in import.c.  I've validated that the @test.pyc
contains the valid magic number, but the marshaller
changes both 0x0a and 0x0d (the most significant word)
into '0xff'.  This doesn't happen when I give no -O
option at all.  I've tried to debug this but lost track
in import.c:find_module.  Whether this is a textmode
vs. binarymode issue (I don't believe so) or some
overoptimization of gcc or what not, I wasn't able to
determine.  Perhaps someone more knowledgeable can help
out?

6) I've tried to be as close as possible to the vc6
build.  So os.name still is 'nt' and sys.platform still
is 'win32'.  One major difference is, that allmost all
extension modules which are builtin by the vc6 build,
are external modules in the mingw32 build.  This should
be ok for most of them, but it is bad for the 'msvcrt'
module because most mingw32 people won't be happy to
have a second libmsvcrt.a in their libpath.  The module
should either be always built in, or should be renamed
(to '_msvcrt' or something).  I'm not sure what is the
right thing.

I used the following build environment:
- autoconf 2.57
- gcc version 3.3.1 (mingw special 20030804-1)
- a native python 2.3.2 with scons 0.93 installed

Btw: All of those are in debian's 'testing' (or was it
'unstable'?) branch.

Attached is the patch.  It is so fat, just because I
included config.guess and config.sub which are needed
by the patched configure script.

Although this form only seems to allow one file to be
attached, I will try to send in a xbuild-py.sh script,
so that you can see, exactly which commandlines you can
use.
msg44880 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-11-11 13:24
Logged In: YES 
user_id=21627

Thanks for the patch. Discussion on python-dev indicated
that it is, unfortunately, not acceptable, due to its
reliance on SCons, so I'm rejecting it.
History
Date User Action Args
2003-11-13 14:31:06yxcvcreate