It happens to replace completely the other programming language and interpreter which share the same first letter.
* python-2.5-avr32-bin.tar.bz2: Python 2.5 binaries for AVR32
The below recipie is taken from http://www.ailis.de/~k/docs/crosscompiling/#python, and an updated configure script is from http://whatschrisdoing.com/blog/2006/10/06/howto-cross-compile-python-25/. I will supply proper Makefile targets and perhaps a proper autoconf-based system down the path
# patch -p0 < Python2.5_xcompile.patch # configure # make python Parser/pgen # mv python hostpython # mv Parser/pgen Parser/hostpgen # make distclean Prepare for cross-compilation (update the host option for your os): #CXX=avr32-linux-g++ \ CC=avr32-linux-gcc \ AR=avr32-linux-ar \ RANLIB=avr32-linux-ranlib \ ./configure --host=i586-pc-linux-gnu --target=avr32-linux --prefix=$HOME/install # make CXX=avr32-linux-g++ \ CC=avr32-linux-gcc \ AR=avr32-linux-ar \ RANLIB=avr32-linux-ranlib \ HOSTPYTHON=./hostpython \ HOSTPGEN=./Parser/hostpgen \ BLDSHARED="avr32-linux-gcc -shared" # make install prefix=$HOME/install/usr \ HOSTPYTHON=./hostpython \ BLDSHARED="avr32-linux-gcc -shared" \ CROSS_COMPILE=yes
Using Christopher Lambacher's cross compile patch against Python 2.5 and passing the toolchain options to configure should allow Python to compile cleanly. I believe that the 'struct stat' and 'stropts.h' issues reported earlier were caused because the configure utility was run against the host libraries, which could have an incompatible timer header.
Type: # python
And start the fun life of developing python applications.