[Aboriginal] Catching up...

[Rob Landley]

So, the big deal last release was that I made Linux From Scratch build
to completion on several targets.  About half of the work there was
making the automated LFS build infrastructure (and I genericized it so
doing a Gentoo bootstrap can re-use most of it), and the other half of
the work was fixing the base system so various things would work.  (Lots
of little patches and config changes to uClibc, having actual passwd and
group files, and so on.)

Nothing like actually building ~50 packages under the target to work out
some of the rough edges of the build environment.

Unfortunately, x86 and x86_64 were the only ones the build ran to
completion on reliably.

On arm, mips, and powerpc I kept getting some kind of subtle race
conditions in make resulting in build breaks that work just fine if you
run that package build a second time.  For example, the "gmp" package
build kept failing with:

  configure: WARNING: you should use --build, --host, --target
  checking build system type... Invalid configuration `xx': machine
  `xx' not recognized
  configure: error: /bin/sh ./config.sub xx failed
  Command exited with non-zero status 1

But it _only_ did it when I tried to build all targets in parallel, and
I could never make it happen when I was _looking_.  (Which is the most
frustrating kind of bug there is.)

My first guess is they have something wrong with their pthread.old
implementations (make fires off a "worker thread" even with -j 1), and
with NPTL so close to shipping I've been poking at the 1.0.0-rc2 release
(which Bernhard hasn't accepted will be 1.0 yet, but oh well).

  http://lists.uclibc.org/pipermail/uclibc/2011-February/044763.html

So really, I want to get uClibc-nptl to the point where I can run the
LFS build on that, and then fix bugs there instead of trying to debug
old infrastructure that's being replaced.

This also means that I should be able to build glibc under uClibc, since
that build was failing because it was shocked (_shocked_) to find a 2.6
kernel that didn't support TLS in userspace.  I.E. bootstrapping a
native uClibc development environment should be enough to natively build
a complete glibc chroot under the result if you want to, but so far I
haven't made that work because glibc is picky (and deluded).

The problem with uClibc-nptl-rc2 is it hasn't been tested with binutils
2.17 and assumes we have assembler features we don't.  Here's the thread
on that:

  http://lists.uclibc.org/pipermail/uclibc/2011-January/044684.html
  https://bugs.uclibc.org/show_bug.cgi?id=3193

And once that was fixed, here's the next bug:

  http://lists.uclibc.org/pipermail/uclibc/2011-January/044701.html

Which turned out to be due to this:

  http://lists.uclibc.org/pipermail/uclibc/2011-February/044790.html


Work continues.  Mostly on weekends at the moment...

Rob