Ports to other architectures was Re: Fedora Core on the Alpha

[Lennert Buytenhek]

On Wed, Aug 11, 2004 at 09:21:46AM +0100, David Woodhouse wrote:

> > > I'm reasonably far with the xscale big endian (armv5teb) port.  Most
> > > things just work, it just takes a lot of time to compile-test things
> > > as I only have one 600MHz processor to work with (and crosscompiling
> > > is not an option because a lot of packages are simply broken with
> > > respect to that, hardcoding CC=gcc, etc.)
> 
> I spent a lot of time trying to get the distro to cross-compile, a
> couple of years ago. The problem wasn't so much hardcoding CC, it was
> mostly the plethora of autocrap scripts which prevented portable
> cross-compilation. They'd run some test on the _host_ and make
> inferences about the behaviour/wordsize/etc of the _target_. 

Yeah, seen that, although I can't remember where.

gtk+'s autoconf at least asks you to manually specifiy some parameters
that it cannot determine by itself in a cache file, and invoke it with
that.

I never really saw the point of auto*, it's not as if it makes things
like crosscompiling actually any easier.  I mean, it doesn't prevent
people being ignorant.


> > They apparently used binfmt_misc to recognise non-native binaries (I think it 
> > was ARM from memory) on an i386 class build machine.  The "interpreter" for 
> > the binaries was a script that used ssh to login to an ARM server and launch 
> > them (the ARM server NFS mounted the file systems from the i386 machine at 
> > the same locations).  This meant that all the autoconf tests which rely on 
> > compiling a test program and executing it worked.  I expect that you could do 
> > the same.
> 
> You can also use qemu for this. In fact I use qemu with binfmt_misc all
> the time on my Fedora/ppc box, for running stuff like acroread. Build
> yourself an ARM chroot, then do cunning things like replacing the
> toolchain with a 'native' i386->arm compiler so it goes nice and fast...

Something just popped into my head: what about using distcc on the ARM
machine, and then making the distcc client machines be fast x86 boxen
where gcc is an x86->ARM crosscompiler?  That would work, no?


> (OK, we have to fix qemu-arm first but...)

Want that too :(

(It looks like it's not all that hard to fix, though.  Once you factor
noexecstack out of the equation, it seems like there's only a few
opcodes missing.  These opcodes only get generated when you compile
for armv5 (armv4 works okay), and give qemu a nice and clean sig4
if you use Paul Brook's three qemu-arm patches he posted.)


--L