[Aboriginal] 83de80c10db8 troubles

Rob Landley rob at landley.net
Fri Apr 20 15:26:09 PDT 2012

On 04/19/2012 09:18 PM, Ken Burk wrote:
> Rob,
> Congratulations on you new gig as maintainer of the Linux kernel
> Documentation/ directory :) I have followed your work for many years
> really enjoy reading and learning from anything you have to share on the
> net.
> I use aboriginal compiled root file systems on all my devices including
> a zipit z2,og droid and 2 netbooks and cant wait to get my hands
> on a raspberry pi that I signed up for a few weeks ago.
> No rush on this but I thought I would let you know the latest version is
> failing to build when chroot to your last release of lfs-bootstrap.
> Version f19ce5e2ec02 builds fine in the same environment.
> Here is where it bailed out when building the native compiler :
> Applying
> /04-19-12/aboriginal-83de80c10db8/sources/patches/uClibc++-unwind-cxx.patch
> patching file include/unwind-cxx.h
> Snapshot 'uClibc++'...
> make -C extra/config conf
> make[1]: Entering directory
> `/04-19-12/aboriginal-83de80c10db8/build/temp-i686/uClibc++/extra/config'
> make[1]: *** ../../.config: Is a directory.  Stop.
> make[1]: Leaving directory
> `/04-19-12/aboriginal-83de80c10db8/build/temp-i686/uClibc++/extra/config'
> make: *** [extra/config/conf] Error 2
> Exiting due to errors (i686 native-compiler uClibc++)

Gotcha.  Thanks for the heads up.

My todo list for this weekend includes fixing the two platform
regressions (armv4l and x86_64), and trying to fix the Fedora build
problem.  Plus there's a new uClibc++ release out I should upgrade to.

> Also just wondering if you have ever built new qemu for lfs-bootstrap,it
> needs glib and likely lots more.

Sure.  I have a qemu git repo on my host, I build from that every once
in a while.

> I also tried an older version of
> qemu which failed (don't remember the error) but was remembering when
> qemu used to be part of the firmware Linux build and think
> it would be sweet to have again someday for building arm without using
> my puppy remaster.

Yeah, I removed it on 2009.  http://landley.net/hg/aboriginal/rev/862

I'm treating qemu as a host tool, something you get from your distro or
build on your distro.  (In theory you can bulid qemu under your target,
but if you're running your target already... chicken and egg problem
there actually being useful.)

The goal of aboriginal linux is to build a system iamge.  That's an
intentional design boundary: what you _do_ with that system image
afterwards is a separate issue. (If I don't draw the line somewhere,
feature creep will recapitulate buildroot.)

Aboriginal Linux tries to be target-agnostic.  You could have a real
versatile arm aboard, or use an emulator other than qemu. The
run-emulatorsh script works with qemu, but you can replace it with
something else (a telnet to your raspberry pi, for example). In theory,
only the run-emulator.sh script would have to change, the other two
stack on top of that.  In practice, supplying HDB and HDC, and specify
extra memory (the QEMU_EXTRA stuff) in dev-environmentsh is
qemu-specific too.

Yes we provide native-build.sh, and the more/*-from-build.sh scripts,
but the control-images are a separate project (with its onw repository)
for a reason. You could make an argument about whether or not qemu
belongs in host-tools.sh, but you don't need it to build system images,
and that's where build.sh stops.

On ubuntu 10.04, "./configure && make" in qemu just works.  I expect I
had to install buckets of dependencies, but it was long enough ago I
don't remember what they were.  Probably covered by
http://landley.net/notes-2011.html#26-05-2011 though...

GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.


More information about the Aboriginal mailing list