[Aboriginal] Latest cross-compiler-x86_64 stopped working as /usr/bin/x86-64-gcc symlink

[Rob Landley]

On 01/30/2017 03:48 PM, Denys Vlasenko wrote:
> Hi Rob,
>
> Needing to test some musl glob() issues, today I downloaded
> 
> http://landley.net/aboriginal/downloads/binaries/cross-compiler-x86_64.tar.gz

Timing. [1]

Aboriginal Linux is mothballed, and is being replaced by two projects:

  toolchain: https://github.com/musl-cross-make [2]
  filesystem: https://github.com/landley/mkroot

And I've giving a tutorial based on the new stuff at ELC next month:


https://openiotelcna2017.sched.com/event/9Ith/tutorial-building-the-simplest-possible-linux-system-rob-landley-se-instrumentscom

The reasons I discontinued the old one last year are described here:


http://lists.landley.net/pipermail/aboriginal-landley.net/2016-May/002567.html

The announcement of the replacement was here:


http://lists.landley.net/pipermail/aboriginal-landley.net/2016-November/002591.html

And my goals going forward (turning Android into a self-hosting
development environment out of the box) are described here (with links
to a long writeup of why, and an hour long talk I gave on the subject):

  http://landley.net/toybox/about.html

Meanwhile, Android has already weaned itself off of gcc and gone to
LLVM, as described by Elliott Hughes (Android's Base OS maintainer) here:


http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008795.html

Who said (when we were discussing building the kernel with an llvm
toolchain, such as the one shipped in the Android NDK):

> i think the "we aren't using gcc any more, and 4.9 was the last
> version we'll update to, and we're not maintaining that any more
> either" message is pretty well understood at this point, so several
> different groups are independently working on this, for different
> architectures. the google folks seem to have gotten further than the
> linaro folks judging by conversation at plumbers this year, but i
> think it's clear to everyone that it's a priority at this point.

Here's a post from Elliott (who maintains bionic and toolbox) about
replacing the rest of toolbox with toybox:


http://lists.landley.net/pipermail/toybox-landley.net/2016-June/008484.html

And here's the most recent time I discussed my longer-term plans with
Elliott in public:


http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008779.html

(Google hasn't explicitly agreed to these plans, but they know about
them and are regularly merging my code.)

Aboriginal Linux's airlock step has already moved into toybox (make
install_airlock), my new root-filesystem build is mkroot and I'm slowly
weaning it off of busybox (I need to finish toybox tar, gzip compression
side, unxz, route, wget, ping, vi, and sh), and I was working on a
kernel build script over the weekend to do qemu test images in. Google's
really big into regression testing, so if I present them with a test
infrastructure using mkroot they'll probably start playing with it...

Part of the reason this bubbled to the top of my todo list again is I
talked with a bunch of people about it at linux.conf.au last week, and
they generally seemed excited about the idea. I've been hugely
distracted by $DAYJOB stuff for the past 6 months but that may finally
be working its way through... (Fingers crossed.)

In addition to the GPLv3 issues, Aboriginal Linux was way too complex to
help much with the upcoming AOSP rewrite: peeling AOSP apart into
orthogonal layers (so you can build a "base OS" for an embedded
iot/drone/pi without downloading tens of gigabytes of source code first)
requires a much simpler approach. Given that Aboriginal is something
like the third reboot and fourth name for the project anyway:

  https://landley.net/aboriginal/history.html

If you need a new toolchain for busybox testing, try musl-cross-make.
Here's some test scripts I used to build it for lots of different
targets over the weekend:

  http://landley.net/temp/

I did a "git clone https://github.com/richfelker/musl-cross-make",
dropped those two scripts in the directory above it, and ran
"../all.sh". (It's in the directory above because I got tired of losing
updates to "git clean -fdx && git checkout -f", it should be easy enough
to strip that part out if you don't accidentally do that a lot. :)

I have no idea if the resulting toolchains actually do what I want yet,
I'm still testing them. (Older versions did but that was 6 months ago
and the build scripts were different.) A couple of architectures I tried
(like cortex-m) didn't build, and there's no support for a few of the
old ones aboriginal did yet (like sparc). But Rich is pretty good about
responding to feedback. :)

Rob

[1] I spent a couple hours today writing up a eulogy for the project to
post on the news page. I'm about half done. The tl;dr is given a choice
between shipping a GPLv3 binary and ending the project, it was an easy
decision. And thus the project ended.

[2] Eventually I want the Android NDK llvm toolchain to work for mkroot
too, which means it needs to build toybox defconfig. See the long thread
most recently starting at
http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008767.html
where Elliott's fixing up the NDK headers to it can build more of
toybox. See also
http://lists.landley.net/pipermail/toybox-landley.net/2016-December/008772.html
in that thread for the difference between "NDK" and "Platform", I.E. why
a toybox built with the NDK can't do everything toybox built with AOSP
can. (Because the NDK doesn't have all the libraries and it needs
selinux annotation to do its job. My current plan for self-hosting is to
set up a posix container using minijail
(https://lwn.net/Articles/700557/) you can chroot into and run builds
under, but we'll see how it goes as we get closer.)