Re: qemu/Scratchbox ideas
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
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.