Cross building python for mingw32

[yxcv]

BPO	841454
Nosy	@loewis
Files	python-2.3.2-mingw32-cross.patch: patch to cross compile python-2.3.2 with the mingw32 gcc xbuild-py.sh: xbuild-py.sh

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-11-11.13:24:38.000>
created_at = <Date 2003-11-13.14:31:06.000>
labels = ['build']
title = 'Cross building python for mingw32'
updated_at = <Date 2006-11-11.13:24:38.000>
user = 'https://bugs.python.org/yxcv'

bugs.python.org fields:

activity = <Date 2006-11-11.13:24:38.000>
actor = 'loewis'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Build']
creation = <Date 2003-11-13.14:31:06.000>
creator = 'yxcv'
dependencies = []
files = ['5681', '5682']
hgrepos = []
issue_num = 841454
keywords = ['patch']
message_count = 2.0
messages = ['44879', '44880']
nosy_count = 2.0
nosy_names = ['loewis', 'yxcv']
pr_nums = []
priority = 'normal'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue841454'
versions = ['Python 2.3']

[yxcv]

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.

[loewis]

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.