Aboriginal Linux 1.2.0.x
This file is taken out of the 'aboriginal-project-188.8.131.52' tarball
This project is a resuscitation of an old version of the famous Aboriginal Linux created by Rob Landley.
Rob developed Aboriginal up to version 1.4.5, early-2016,
then retired from the project. See the history and retirement
Back in the "early days", Rob used uClibc and Busybox as the
core of Aboriginal. Later, he gradually replaced Busybox applets with
his own creation, Toybox. Then, mid-2015, he moved from uClibc to Musl.
I prefer uClibc over Musl, mostly due to the former's better
compatibility with glibc. I also have no motivation to replace Busybox
with Toybox. Hence, I have stayed with version 1.2.0, that was released
Why use it?
As a Linux developer, I have a need to compile some utilities statically. That is, they do not use any shared libraries.
I use these utilities in the initrd/initramfs, but also in
the main Linux filesystem. The single greatest advantage of a static
utility is that it is completely self-contained and will work in any
Linux, into the future -- there will never be any library compatibility
The downside is that static utilities are big, as,
essentially, they have the library functions bullt-in to them. This is
where uClibc and Musl come in, as their libraries are "lean and mean"
and will produce much smaller binaries than if the utilities are
compiled against glibc (Gnu libc, which is what all the Linux
To give an idea of the size difference, 'dmsetup' (a utility
in the LVM2 package) is 128KB (stripped) when linked against shared
libraries, 517KB (stripped) when linked statically against uClibc. A
smaller utility, 'hwclock', is 36KB versus 92KB.
Another utility that is interesting to compare is Busybox.
Configured fairly full-featured, as I use in Quirky and EasyOS, linked
against shared glibc, the 'busybox' binary is 850KB. Compiled in
Aboriginal linux and linked statically against uClibc, it is
966KB. The static utility is not much bigger!
Another place where you might use static utilities, is during
early bootup of Linux, in the main filesystem. Even if the system has
been "stuffed up", with maybe incompatible libraries installed, if
'init' and the basic bootup utilities are static, then they will still
work and get you to a commandline.
Oh, one more thing -- a 32-bit static utility will work in a 64-bit system. No need for 32-bit libraries.
I have been using version 1.2.0 for years. as a chrootable
filesystem. That is, I can chroot into it, from whatever host distro I
am running (usually Quirky or EasyOS), and then can compile source
packages that will be linked against uClibc.
Recently though, I hit a problem, was unable to compile
package 'LVM2', as it requires the 'fmemopen()' function, that is not in
Or rather, it is, but not enabled. I was using a precompiled x86_64 root-filesystem, downloaded from Rob Landley's site.
Rob uses uClibc version 0.9.33.2, which is the last official
release of the uClibc project. That was in 2012. I discovered that there
are additional glibc-compatibility options, including fmemopen(), so, I
needed to recompile uClibc...
I downloaded 'aboriginal-1.2.0.tar.bz2', which is the source
code, which can be used to compile architecture-specific
root-filesystems, for example x86_64 or armv6l. For the record, this is
where to get it:
I modified the configure option for uClibc, and also bumped
the kernel version from 3.5 to 4.3 (got that out of aboriginal 1.4.5),
then compiled for a x86_64 target. Then had a new x86_64 chrootable
And, LVM2 compiled!
I thought that others might find this useful, so have forked
it as a new project. Version numbering will be "1.2.0.x", where the "x"
is my enhancements. At the time of writing, it is "184.108.40.206".
The project is setup as three folders, "binary", "source" and
"work". In the latter folder, you will find a HTML file that explains
how to use aboriginal-1.2.0.x.
Myself, and anyone else who is interested, can continue to
pump steroids into this old "1.2.0". Reconfiguring uClibc and bumping
the kernel, were just the first step.
The original official uClibc project was active on the
project's git-repository until mid-2015, when work stopped, and a new
project, 'uClibc-ng' took over.
I checked-out the latest from the official uClibc git-repo,
last commit was 2015-07-05. Put it in aboriginal, but compile failed,
with a missing symbol "__builtin_unreachable". This was introduced with
gcc 4.5, however, aboriginal 1.2.0 uses gcc 4.2.1. I think that you
might guess where this is heading...
I bumped gcc to version 4.5.4, and modified some of the previous patches, but compile failed.
Rather than chase that one, I backed off, kept the uClibc
0.9.33.2 and gcc 4.2.1. After all, there is no pressing need to upgrade,
as all the source packages that I want to compile, busybox, etc., do
Anyway, there could be lots of fun for someone, to play with updating the packages.
In 'rootfs-220.127.116.11-amd64', the x86_64 root-filesystem
compiled by aboriginal 18.104.22.168, I have put in build scripts for
'ncurses', 'bash', 'busybox', 'coreutils', 'patch' and 'LVM2'.
A project would be to move those into the 'aboriginal-1.2.0.x' source tarball.
Another useful project would be to add a "aarch64" target. Even "armv7l", as currently there is only "armv6l".
Lots of fun! Do read the help-file in the "work" folder.
The original official uClibc site:
March 9, 2018