[Aboriginal] 1.2.0 is out!

Rob Landley rob at landley.net
Fri Aug 24 03:45:33 PDT 2012


That took a very long time. Sorry, my day job has reduced my hobbyist
programming time to somewhere around 10 hours a week if I push, by a
combination of soaking up all my time and leaving me exhausted at the
end of it.  Of that, toybox has sucked away most of it, and being made
kernel Documentation maintainer is fighting for the scraps.

That said, I finally caught up with the kernel releases, and the
lfs-bootstrap images for various targets are uploading now. I'm writing
up a not particularly epic bisection battle I had as an example of
real-world problem bisection under adverse conditinos.

The release notes on the web page cover most of it, but here's a bit
more detail on some of the more recent fixes:

The Fedora bug turned out to be that none of the other shells were
dynamically linked against libgcc_s.so.1, which the build was putting
the TARGET version of in LD_LIBRARY_PATH before calling the shell during
configure-target-libstdc++-v3 (to make libsupc++.a for uClibc++ to
consume). But fedora's /bin/sh was. This didn't cause a problem when it
was an OBVIOUS target binary and thus the dynamic linker wouldn't try to
link in an arm binary x86_64 because the ELF constants were wrong, but
an x86-64 binary did get linked in and then it died because uClibc
wasn't installed on the host. The fix was to explicitly tell it SHELL=sh
so it used busybox ash which is A) statically linked, B) never links
against libgcc_s.so.1 even when it isn't.

The arm target had several problems from 3.2 to 3.5, stemming from the
fact that "arm versatile" apparently never worked on real versatile
hardware, but only on qemu's emulation which apparently doesn't count.
The upstream arm maintainers noticed some discrepances in the interrupt
routing and fixed it to make the documentation instead of existing
reality. So far nobody's found an actual arm versatile board to test
this on; I patched the kernel code back to match what qemu expects. We
can adjust qemu, but then new versions wouldn't be compatible with
existing qemu releases. Me, I just want something that works, I don't
care if it's a completely synthetic board that doesn't match any real
hardware, the important thing is that the userspace code in the root
filesystem works on real hardware, and that qemu can run that code.

The ".config is a directory" problem with uClibc++ turns out to be that
A) Garrett was using relative paths in a makefile, B) the root directory
of some systems has a ".config" directory containing some random file
that says "Trolltech". So when the makefile tries to include
"../../.config" (which won't be there during the initial configure call,
because we haven't created it yet), it does so using an include syntax
that says "it's ok if we don't find this", but since it's not looking
for an absolute path it falls back to a search path before giving up,
and it starts with "/usr/include", and "/usr/include/../../.config"
finds the one in the root directory, which is a directory, and it barfs.
The fix: turn the relative path into an absolutepath when setting the
variable, I used "shell readlink -f" on it.

The sh4 bug is that the driver grew another port read that either works
on real sh4 hardware or is a NOP (most likely a NOP), and qemu's
emulation kills the emulator if a driver attempts to read from an
unknown port. I just patched the kernel to read from a known port that
will always return 0, the proper fix is to make qemu return 0 for this
port instead of dying.

Plus the usual stuff like rebasing the perl removal patches,

I still haven't fixed Piotr's mdadm bug. It's not a kernel thing, it's a
uClibc .configuration thing. I'll have to do another release for 3.6
anyway so it can go into that.

Meanwhile, I'm playing with toybox and musl, and adapting Aboriginal to
test both of those.

Rob
-- 
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