Cross Compiler for Python?

[norseman]

I think I should have not used the 'reply' button but rather sent it 
back through the python-list at ...

So here here goes.
===============


Hendrik van Rooyen wrote:
> Up to now, I have been innocently using the vanilla python
> that comes with the Linux distribution (Suse in my case).
> 
> For the past few days, I have been playing with a little
> device called an eBox - it is basically a 486 with 128Mb
> memory, and a 1Gig pcmcia flash drive.
> 
> We want to try to use this as an industrial controller, so
> I want to load python onto it.
> 
> So I downloaded the sources, and got them into the box,
> over its ethernet connection.
> 
> Then I got stymied - the configure script will not run, 
> because the "distribution" has no C compiler - it is 
> basically a kernel, and Busybox, with precious little else.
> 
> So I googled, and I found mobile python, and portable python,
> both aimed at windows. - no good to me.
> 
> Adding "embedded" to the Google string is also useless,
> as it basically brings up instances of embedding the
> interpreter into another app, not for small processors.
> 
> So how does one do a compile of python on one machine
> aimed at another one?  - All I want is a vanilla installation
> with the stuff in all the usual places.  And just to make matters
> interesting, the two Linux boxes I have available are both
> 64 bit dual core animals, one Intel, one AMD...
> 
> I don't need much more than the interpreter, sys, os, sockets
> and ctypes.
> 
> Alternatively, where can one find a set of binaries for
> 32 bit Linux?
> 
> Looking for some sane advice please.
> 
> - Hendrik
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
> 
==================================================
In case all else fails:

This is not a cookbook answer, but:
	1) gnu's gcc will compile to 16,32 or 64 bit intel architectures
	   OK, the 32 bit version compiles to 16 or 32 & the 64 should.
            The 64 will run 32 bit programs, including the 32 bit gcc.
            chgroot can be (messy but) useful to maintain separation.
	2) info gcc  and look for compiler directives
	      then  info nasm  and look for directives
	      same for the linker
	   I'm not specific because I use Slackware and different
            distros can use different modules. You may have an assembler
            with a different name. Switches can be different and so
            forth.
On Slackware the installpkg (for tarballs already compiled) records the
  locations of where things go in /var/log/packages. I have to assume
other distros have something similar since these are used to remove
things later. Can we say 'updates'?  If not you will need to wade
through the .configure and Makefiles to root out what happens to get
'vanilla' locations.

Like I said, it's not cookbook, but it will get you there and you will
gain quite an insight into Linux.  While the path may not be well marked
in Linux, there usually is one.

Sorry I don't have a more straight forward approach.


Steve
norseman at hughes.net