[Aboriginal] Couple of bugs.

[Rob Landley]

On 04/07/2011 04:21 PM, David Seikel wrote:
> When using SYSIMAGE_TYPE=ext2 (or anything that is not squashfs), then
> the squashfs stuff is not built.  The bootstrap stuff still tries to
> use the non existent mksquashfs though.

Argh.  Yeah, that's a problem.

> The bootstrap tarballs are being named foo.tar.gz-i486.

Um, details?  (I haven't seen that one.)

> Both easy enough to fix, and you might have done so already anyway.
> This is with the last release.

The first one's a design issue, which makes it tricky.

The point of host-tools.sh is to sanitize the host environment for the
rest of the build.  It's not _just_ to make sure you've got everything
you need and known working versions of each, although with many versions
of many distros out there, it's an issue.  And the bugs that produces
are often really hard to diagnose, as this recent commit attests:

  changeset:   1335:ffb07a48a960
  user:        Rob Landley <rob at landley.net>
  date:        Fri Mar 18 05:58:35 2011 -0500
  files:       sources/download_functions.sh
  description:
  If sha1sum isn't installed, download falls back through all the
  mirrors repeatedly downloading stuff, without explaining why it
  failed.

That was a fun one.  (By its nature download.sh has to run before
host-tools.sh so it runs in the unsanitized environment, so even today
it doesn't get the benefit of a known host environment.)

But the real problem host-tools addresses is _removing_ stuff from the
$PATH, making sure the various ./configure stages don't find things like
python and ncurses that your host has but the target doesn't.  Some
people think the more your development environment has installed on it
the better, but this is very much _not_ true for cross compiling.  (And
to be honest, selinux exists to make the fortune 500 happy, not to
accomplish anything useful.)

Anyway, getting back to the point at hand: host-tools.sh sets up the
environment for the rest of the build, culminating with the system
images.  This is an artifact of that: it's not setting up anything the
steps leading up to system-image.sh don't need.

The control images aren't really part of the aboriginal linux build,
they're a seperate layer that really should be their own project.
(Nothing says you can't boot up arch linux on an arm board and run the
lfs-bootstrap stuff on that.  I haven't TESTED it, of course, but
there's no real reason it shouldn't work.)

Hmmm...  host-tools is already building distcc, which also isn't really
part of the build.  I suppose squashfs can become unconditional...  but
it's ugly.  Lemme think if there's a better way to do this.  (I'd
already have split control image building out if it didn't need to use
sources/download_functions.sh...)

Rob

 1302221507.0