ext Peter Naulls wrote: [ sorry for clipping away so much ]
To mitigate this, one option would be to allow the chroot to install x86 packages into the ARM chroot. In particular, you could "just" install the x86 package of perl, and other packages that might be speed crucial. For GCC, you could make a cross compiler that looked just like a native compiler, except it happened to spit out ARM binaries.
When you install those x86 binaries into that chroot, you need to either make them static (since /lib & co are populated with ARM stuff) or build them specially so that they use (link to) stuff from elsewhere (which is what sbox does). You may need to also put them elsewhere in order to make room for the target things (which is again what sbox does).
Also, creating static binaries with glibc is a bit interesting (I came to the conclusion that effectively you can't really, although helloworld things naturally can be; nss* and other dlopen() users make static life a pain).
I'm absolutely not saying that you shouldn't pursue this way, since as you said, you can get a working (although IMHO quite slow) build environment relatively easily. Just that the difference to scratchbox might not be that great once you start optimizing it for speed.
I think you'd be approaching the same target from a different direction.Again, if you can get it to work, I'm willing to bet that sbox can use most of what you'd create with very little modifications. So I don't really see too much duplication of effort, at least not initially.
/lauri