[Aboriginal] Why more/chroot-splice.sh doesn't work anymore.

[Rob Landley]

So I'm poking at lfs-bootstrap this weekend, and my design assumptions
seem to have crossed paths and cancelled each other out at some point.

Problem: building big things under qemu is slow enough that for test
purposes, it's nice to smoketest stuff on i686 under chroot and _then_
worry about building it for the target.  I can set up such a chroot by
hand, but it's tedious and there should be an easy way to _automate_ it
given a root filesystem and a control image filesystem.

After the build, extracted versions of the root filesystem and control
image are available in the build/root-filesystem-$ARCH directory and
build/control-images/lfs-bootstrap directories.  Many moons ago I made a
more/chroot-splice.sh script that copies them together and prints out
the sudo command line you have to run to chroot into it, and the command
line you run inside it to kick off the build.  (It doesn't do these
steps itself because none of my build scripts ever require root access.
 Possibly this script should call sudo anyway, since it's really an
optional development/debugging thing and the whole POINT is to set up a
chroot?  Anyway...)

Once upon a time, /mnt/init would check if the root filesystem was
writeable, and if so it would skip the setup-chroot step: instead it
would just build and install packages into the host root filesystem.

I suspect that behavior was in the gentoo/LFS bootstrapping stuff I did
for Qualcomm's Hexagon port last year, and never actually made it into
the reimplementation I did for public consumption.

However, the chroot-splice script was written on the assumption that
/mnt/init did that.  If it _doesn't_, then it copies the gigabyte of
lfs-bootstrap files in /mnt into the new chroot (because the copy is
using find -xdev).  And then it bind mounts /mnt over that.  This may
actually work (never let it run long enough find out), but it's HORRIBLY
inefficient.

So yeah, just fixed that.  Then I need to track down why one of m4's
configure tests ("does some string function work in linear time,
apparently not") is hanging forever.  I remember looking at it before
and it was setting an alarm() to kill it after a few seconds, and the
alarm was never triggering due to uClibc's signal handling with
-lpthreads being crap.  I believe I fixed it with a background process
that did "while true; do sleep 5; killall nameofthetestbinary; done".

Which means I should look at the current uClibc release again to see if
signal handling sucks less under NPTL.  But lemme re-establish an LFS
native build baseline first.  And possibly update it to the current LFS
release...

Rob

P.S.  I used to post this kind of stuff to my blog, but I'm trying to
post it here now.  Lemme know if you have a preference where it should
go?  If I do post it here, the list traffic is mostly me blathering on
about technobabble details, but if I blog it the list traffic tends to
get really sparse and the comments I get about it are in private email
instead of here...