Issue 841454: Cross building python for mingw32 (original) (raw)

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:

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

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

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

  4. '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?

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

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.

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.