embedded ubuntu?

[Jerry Haltom]

I don't know if I particular agree with this being a flaw with dpkg as
much as with the actual software we're trying to build. There are many
pieces of software which execute GCC to build a program which is run
immediately after to help with the build.

If you want this program's build to "run as expected", then either a)
GCC should build it for the local arch even though the end destination
is another arch or b) the local machine must be able to run the remote
code base.

I guess the real question is, is this valid? Should a programs source
code be allowed to run native code that it itself generates? Up to now,
yes. Changing that would be a pretty big diversion in current Debian
policy/assumptions.

Scratchbox solves this by using binfmt_misc and some trickery to set up
a "fake" Debian chroot, which allows executing non local arch code. This
works pretty well... but it's a "fake Debian".

I think, for now, the best case is to just compile the package on the
expected arch, or qemu. Long term would be for Scratchbox to be more
Debian-integrated.

qemu isn't really that slow. It's quite good enough for doing a basic
port.

Another solution to the speed problem really is to fix dpkg so we can
use binary-arch-indep. That would really. ;)

On Tue, 2006-07-18 at 09:52 -0700, Dan Kegel wrote:
> On 7/17/06, Jerry Haltom <wasabi at larvalstage.net> wrote:
> > ... an actual
> > Debian/Ubuntu port would require being built on "real hardware", not a
> > cross compiler.
> 
> If so, that's arguably simply a problem in the debian/ubuntu build
> system.  One can imagine a fully-cross-built debian/ubuntu.
> It's hard, but potentially doable, and most of the work would
> probably be just fixing bugs that make it hard to cross-build various
> packages.
> - Dan