[ python-Feature Requests-848910 ] Enable crosscompilation

SourceForge.net noreply at sourceforge.net
Thu Nov 27 03:17:58 EST 2003

Feature Requests item #848910, was opened at 2003-11-25 13:55
Message generated for change (Comment added) made by hohjg
You can respond by visiting: 

Category: Build
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Jörg Hoh (hohjg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Enable crosscompilation

Initial Comment:
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). 


>Comment By: Jörg Hoh (hohjg)
Date: 2003-11-27 09:17

Logged In: YES 

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


Comment By: Jörg Hoh (hohjg)
Date: 2003-11-26 21:25

Logged In: YES 

I've already have a patch (which is mostly a port of
to the current version), and extended it further, so it
compiles now really all modules.

The compilation itself isn't as simple anymore as
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 :-)


Comment By: Neal Norwitz (nnorwitz)
Date: 2003-11-26 21:09

Logged In: YES 

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?


You can respond by visiting: 

More information about the Python-bugs-list mailing list