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
