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

Re: qemu/Scratchbox ideas



On Tue, 2004-05-04 at 14:48, Peter Naulls wrote:
> 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
> further.
> 
> 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.

Actually for various reasons I rather like this idea. I like the idea of
having what basically looks like a native compile environment, without
any cross stuff at all. 

The only problem is compile speeds, as emulating gcc is going to be slow
(how slow is it?). The obvious answer is to install distcc becasue that
enables you to use cross compilers anyway on the remote machine(s).

And throwing more CPU time at things to simplify your life is what
computers are for.

Have you made a chrootable executable on 386 arm distro?

Justin




Reply to: