[Toybox] Android Testing

[Rob Landley]

On 03/02/2015 12:26 PM, Trevor Drake wrote:
> I don't mind at all. I've got some usable going. I'm subscribed to the
> list as I was going to reply to last months Building Android Thread
> originally before It became apparent that Gmail Sucks balls at
> replying to archived threads that it's never seen.
> 
> I didn't get round to testing in qemu you can still do a "make toybox
> linker" which should result in toybox linker libc libm and libdl.

Alas Aboriginal Linux's self-hosting bit-rotted a bit recently because I
was using host shell features that the bash 2.05 build didn't like, and
then the pending release is having problems because distcc is
segfaulting... but only on x86. The native toolchain works.... until it
gets to the perl build, at which point it complains "Unable to find a
perl 2.36242958346314e-310" which is just _sad_.

(The really sad part is I reverted the kernel code _and_ the qemu
version to the previous one each, and it still doesn't work. Ther hasn't
been a uClibc release since 2012, and my toolchain is stuck at the last
GPLv2 releases of gcc and binutils, so I have no idea WHERE it's getting
this floating point glitch from. Sigh. Revert to an old aboriginal build
version and update things one by one, looks like. Anyway, that's why I
got a toybox release out (builds LFS to the end on mips and arm) but not
an aboriginal release yet...)

> tt's not like the use of Android's init is a requirement and you can get
> all the Android kernel functionality in the Mainline ( I think there's
> netfilter patch still out of tree )

Tim Bird's been working to bring the two together since something like 2011.

> I really had wanted to get this
> patch merge [ https://android-review.googlesource.com/#/c/137050/  ]
> which I need to "fix" up this little project but I think I've just
> found a rats nest under a seemingly innocent 1 line change to a
> Makefile :\ so that is a battle for another day.

Many moons ago I wrote up
https://speakerdeck.com/landley/developing-for-non-x86-targets-using-qemu and
did it as a presentation at like three different conferences. (Another
one of those "it's about 8 hours of material, I had 45 minutes" things.)

It's something like 6 years old now, and I really need to redo it, but
it gets across the basic idea of a minimal self-hosting system, the
simplest native development environment capable of rebuilding itself
under itself and building linux from scratch under the result.

If you cross-compile such a minimal development environment and then
boot it under an emulator (or on appropriate target hardware) and
natively compile under the result, you should never have to cross
compile anything again, which makes life MUCH easier.

My goal for Aboriginal Linux was then to bootstrap linux distributions
under the result. Red Hat only wants to build under Red Hat, Debian
under Debian, Gentoo under Gentoo, and so on. They're full of baked in
assmptions about the host build environment that come from _nowhere_,
they just evolved and were propogated over many years without ever being
documented or reproduced.

(No seriously, you'd think Gentoo would be the easy one, but I spent a
couple days with the _founder_ of Gentoo trying to make it work a few
years ago: http://landley.net/notes-2011.html#23-10-2011 and
http://landley.net/notes-2011.html#26-12-2011 for example. Gentoo is as
tangled a mess of recursive assumptions as any of the others...)

Anyway, my desire to pick apart Linux distros kinda rolled to a stop
when I worked out why Linux on the desktop was never going to happen
(let me know if you want links for that, I have so many) and got
replaced by "turn the billions of android devices people already have
into usable low-end development workstations and let Moore's Law solve
the low-end part").

Which brings us to today. I'd very much like to get the Android build
working under my minimal development environment (or equivalent: I got a
self-hosting build that builds LFS under the result down to 7 packages
but would like to swap out almost all of those packages for alternatives).

Oh, and my "bootstrap full-blown linux distributions" plan was basically
"bootstrap Linux from scratch and then adjust for distro needs", but
Android has additional licensing considerations. They're not going to
add Gnu Make because they couldn't ship it, so I need to write a new
"make" for android. That sort of thing. The _hard_ one here is git:
their build is tied to it, but it's GPL. Cloning mercurial is easier,
but that's not what they use...)

But the first step is dismantling and understanding the android build.
Which you've made more progress on that I have... :)

> So.. To The Mailing List! :)

Forwarded yesterday, today I forgot to hit "send" again.

Rob

 1425441692.0