| Aboriginal Linux 1.2.0.x
This file is taken out of the 'aboriginal-project-1.2.0.2' tarball 
 This project is a resuscitation of an old version of the famous Aboriginal Linux created by Rob Landley. 
 Background
Rob developed Aboriginal up to version 1.4.5, early-2016, 
then retired from the project. See the history and retirement 
announcement:
 http://landley.net/aboriginal/
 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 
in 2012.
 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 
issues.
 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 
distributions use).
 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.
 Version 1.2.0
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
 uClibc.
 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:
 http://landley.net/aboriginal/downloads/aboriginal-1.2.0.tar.bz2
 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 
root-filesystem.
 And, LVM2 compiled!
 Version 1.2.0.x
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 "1.2.0.2".
 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 
compile.
 Anyway, there could be lots of fun for someone, to play with updating the packages. 
 In 'rootfs-1.2.0.2-amd64', the x86_64 root-filesystem 
compiled by aboriginal 1.2.0.2, 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.
 Links
The original official uClibc site:https://uclibc.org/
 https://git.uclibc.org/uClibc/
 
 uClibc-ng site:https://uclibc-ng.org/
 
 Regards,Barry Kauler
 March 9, 2018
 Blog: http://bkhome.org/news/
 
 
 
 |