[Patches] [ python-Patches-1006238 ] cross compile patch

SourceForge.net noreply at sourceforge.net
Tue Nov 8 03:12:22 CET 2005


Patches item #1006238, was opened at 2004-08-09 17:05
Message generated for change (Comment added) made by jdalambert
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Build
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Daniel Goertzen (goertzen)
Assigned to: Nobody/Anonymous (nobody)
Summary: cross compile patch

Initial Comment:
Here's a cross compile patch I prepared a while ago but
never got around to submitting.  I've been using it
happily for months to cross compile python for embedded
systems.

Below is a descriptive excerpt from the patch.  Also
note that the patch modifies configure.in, but not
configure.  You will need to regenerate configure with
something like 

autoconf configure.in >configure

This patch is inpsired from work by Klaus Reimer at
http://www.ailis.de/~k/docs/crosscompiling/python.php

+ Cross Compiling
+ ---------------
+ 
+ Python can be cross compiled by supplying different
--host and --build
+ parameters to configure.  (Python is compiled on the
"build" system
+ and executed on the "host" system, in case you forgot
:).  Python is
+ tricky to cross compile because it needs to execute
parts of itself
+ during construction.  To work around this, make's
VPATH feature is
+ used to compile a native python in the subdirectory
"buildpython".
+ When parts of python need to be executed during
construction, the
+ "buildpython" versions are used.
+ 
+ A consequence of using the VPATH feature is that you
may not do a
+ cross compile build in the source directory.  In
other words, do this:
+ 
+ mkdir mydir
+ cd mydir
+ ../Python/configure --host=powerpc-405-linux-gnu
--build=i686-pc-linux-gnu
+ make
+ 
+ Cross compiling works well under linux, mileage may
vary for other
+ platforms.
+ 
+ A few reminders on using configure to cross compile:
+ - Cross compile tools must be in the PATH.
+ - Cross compile tools must be prefixed with the host type
+ (ie powerpc-405-linux-gnu-cc,
powerpc-405-linux-gnu-ranlib, ...)
+ - CC, CXX, AR, and RANLIB must be undefined when
running configure and
+ make.  Configure will detect them.
+ 
+ If you need a cross compiler, check out Dan Kegel's
crosstool:
+ http://www.kegel.com/crosstool
+ 
+ 


----------------------------------------------------------------------

Comment By: David Lambert (jdalambert)
Date: 2005-11-07 20:12

Message:
Logged In: YES 
user_id=845425

Hmm. not so much luck here. I get the following error after
patching then autoconf. I am running on Fedora Core 4.

Any suggestions?

[dlambert at lambsys Python-2.4.2]$ autoconf configure.in
>configure
[dlambert at lambsys Python-2.4.2]$ ./configure
configure: error: cannot run /bin/sh ./config.sub
[dlambert at lambsys Python-2.4.2]$

----------------------------------------------------------------------

Comment By: Robsa (robsa)
Date: 2005-10-13 06:54

Message:
Logged In: YES 
user_id=1277505

Just thought I'd let you know that this patch works against
Python 2.4.2. I had Python running on my custom AT91RM9200
board (ARM920T core) in about 20 minutes.

*snaps* for Daniel!!

----------------------------------------------------------------------

Comment By: Daniel Goertzen (goertzen)
Date: 2005-04-13 12:36

Message:
Logged In: YES 
user_id=843814

It still works for me, so I've had limited interest in
working on it further.

I think a "real" cross compile patch will involve
significant refactoring of distutils and the main setup.py
script.  Should this start with a PEP?


----------------------------------------------------------------------

Comment By: Ned Ludd (solarx)
Date: 2005-04-09 15:43

Message:
Logged In: YES 
user_id=148412

Any progress with this on? 
python and perl are two of the last major things to overcome
in the x-compile world.

----------------------------------------------------------------------

Comment By: Mike Frysinger (vapier)
Date: 2004-10-26 11:00

Message:
Logged In: YES 
user_id=114429

we've been using this with uClibc for a while now and it
works great ...

ive personally built (on amd64) & deployed (on
x86/ppc/arm/mips/sh4) python ... would great if this finally
made it into the official sources :)

----------------------------------------------------------------------

Comment By: Jeff Epler (jepler)
Date: 2004-10-20 20:08

Message:
Logged In: YES 
user_id=2772

This patch applies cleanly to today's CVS head.

If building in the source directory while cross compiling
fails, please make configure complain about it.

This patch makes the build process invoke make recursively,
which is a big minus.  I'd rather see pgen built with a
HOSTCC and just assume python is available on $PATH for the
setup.py step.  There's no reason to build all the shared
modules in buildpython, either, which would speed things up
a fair bit.

On to how it worked for me:
Not cross-compiling, this produces no unexpected test
failures in "make test". (redhat9)

Cross compiling for i386-pc-bsdi2.1 everything goes fine
until it tries to run buildpython and make shared modules,
but shared modules don't work in the first place on bsdi2. 
I did not test the resulting Python binary.

Cross compiling for i386-redhat-linux (libc6) some
extensions fail to build, but this could be because my
header files for the cross-development environment are not
complete.  Running "make test" tries to invoke the
"buildpython/python" and doesn't work.  Running it manually
I get some skips due to modules that did not build, but
everything that did build seems to pass. (OK, so I wrote
this before the tests completed, but they're off to a good
start)

I currently cross-compile python 2.3 for win32 (mingw), and
until recently cross-compiled it for bsdi2 and redhat6. 
However, I did not use configure or the included makefiles
to do this (in order to integrate in a non-recursive build
procedure that builds several packages), so this patch is
unlikely to benefit me directly.

I don't think this patch is ready to be applied.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1006238&group_id=5470


More information about the Patches mailing list