[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

qemu/Scratchbox ideas

This builds on some discussions I've had with Wookey about various build
ideas, and talking with the Scratchbox people.  It doesn't neccessarily
conflict with Stag issues, and in fact it could work alongside it, but
as the details of Stag don't affect this much, I won't mention it any

Part of the problem of Scratchbox for me is that it's so damn big.  I
understand why it is, and what it's trying to achieve by being so.
Fine.   Also, anyone who's played with the recent Debian packages of it
will realise how mature it's become, and how capable qemu is now with
it - you don't really need a native target machine at all.

In fact, and the point of this post, is that you don't actually need SB
at all. It's possible, with the right runes, to chroot into a ARM
filesystem image (e.g a full Debian ARM system), and run stuff.   You
will find you won't get too far however - there are obvious issues with
double word ordering when running perl (e.g installing packages), and
some unimplemented syscalls.  Nevertheless, it's quite impressive that
it can be done at all.

So, where does this leave us?  Well, assmuing that qemu gets fixed
eventually, which seems likely, you could download a relatively small
Debian ARM image (say, 50MB), and cross compile stuff with the only
magic being the emulation of ARM binaries, and none of the other stuff
that SB has to do to wrap things up so they work.   You could easily
pull down new packages if you needed to them to build things.

The downside is speed - all user space is now emulated - especially for
compiling, unlike SB we're running a native compiler, not an x86 cross
compiler running at full host speed.  How much of an issue that would
be would depend upon some benchmarks being done, and the raw speed of
your system.

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.


Peter Naulls - peter@chocky.org        | http://www.chocky.org/
GCC for RISC OS                        | http://hard-mofo.dsvr.net/gcc/

Reply to: