Python is awful to crosscompile. I've done it with the help of that 
site ( 
http://www.ailis.de/~k/knowledge/crosscompiling/python.php), but 
I still had to patch the setup.py myself. 
 
The wish: 
 
Could you avoid to add the standard include path (usually 
/usr/include) to the include paths (in setup.py)? It confuses my 
crosscompiler (for which /usr/include isn't applicable, because it 
produces code for a different plattform and endianess), because 
the includes given by commandline to the gcc are searched 
before the standard include paths. And if there are files with the 
wished names, it will produce lots of errors and warnings. 
 
The second one (a more longterm wish) 
 
Could you split the build process into 2 parts? A part which is 
plattform independet (the (cross-) compilation of the python-binary 
and all required binary libraries), and a plattform specific one, 
which is then running on the target plattform. 
This would help me and other people crosscompiling python for 
more plattforms and embedded systems, which haven't an 
available native compiler (or the plattform isn't suppossed to run a 
compiler because of its limited ressouces). 
 
 

Logged In: YES 
user_id=33168

I don't think anyone would take issue with supporting
cross-compilation.  Your requests seem reasonable, although
not necessarily easy.  :-) However, I don't think many
(any?) developers cross-compile.  Probably the only way to
support cross-compilation would be if you could produce a
patch.  Even a patch that solves part of the problem could
be beneficial.  How would you like to make a patch?

Logged In: YES 
user_id=359136

I've already have a patch (which is mostly a port of
http://www.ailis.de/~k/knowledge/crosscompiling/python.php
to the current version), and extended it further, so it
compiles now really all modules.

The compilation itself isn't as simple anymore as
./configure
make 
make install

I can submit a simple patch, which enables setup.py to get
some  information of the environment instead of distutils.
These patches aren't nice (in fact I would call them a
really hack), especially the patched Makefile.

I'll will do it tomorrow morning, but don't expect to much
from it :-)

Logged In: YES 
user_id=359136

Ok, here comes my patch (for python version 2.3.2) 
 
For the Makefile: It introduces a new Variable HOSTPYTHON; this is 
initially set to BUILDPYTHON, but for crosscompilation purposes it 
should be set to name of a python binary, which runs on the build 
machine. 
In calls to setup.py the variable CROSS_COMPILATION is set to "yes". 
 
In the setup.py we check for the value of CROSS_COMPILATION; if 
not set to "yes" , LIBDIR and INCLUDEDIR are taken from calls to 
distutils, otherwise we get it from the corrsponding environment 
variables (but the Makefile doesn't export them, because I don't need 
them anymore).  
 
In all cases don't add /usr/lib/, /usr/include and /lib to the search pathes 
of the compiler, because these pathes are searched first for include files 
and libraries (before the default path settings from the compiler; so a 
crosscompiler will always use the host includes instead of the includes 
of the target plattform). 
 
Here (http://www.ailis.de/~k/knowledge/crosscompiling/python.php) is 
described how to use that Makefile. 
 
Please note: This patch works for me, and probably it isn't usefull to 
include it into the distribution. But please look at the changes of the 
include and library pathes, they won't affect all the native builders, but 
may help alot of people who do crosscompiling. 
 

Logged In: YES 
user_id=55188

BTW, where's your patch?
I couldn't find the patch for 2.3.2 you've created from your
site. :-)

Seems out-of-date, more recent efforts should go into a new issue IMO. 

This issue focus on generic aspects of cross-compilation, as issue
1006238 (patch). I think issue 660095 (if still valid!) is akin to this
problem.

Agreed.