[Aboriginal] legacy builds

[Rob Landley]

On 06/16/14 16:18, Carlos Breviglieri wrote:
> Hi, I've recently came across aboriginal and it felt like jackpot for
> the problems I currently have with my toolchain. I mainly target x86_64
> but will try arm asap. I do mostly scientific HPC code and must support
> legacy kernel and compilers (think kernel 2.6 and gcc < 4.3).

The gcc I build is 4.2.1 with binutils 2.17 (the last gplv2 release of
each). It's also simpler because they haven't broken out MPFR and GMP
and such into separate packages yet. Downside: no armv7, armv8, or
micrblaze support. (Might be able to fish armv7 out of the repo. Did so
for binutils, haven't done so for gcc yet. More interested in
http://ellcc.org long term.)

> I would like to know if it is possible to do so, in principle, with AL.
> I did try changing the download.sh to point to older versions and it
> failed during patching obviously... I suspect it is possible, but would
> like to hear if I am going way over the project original design goals or
> if I should look for something else.

Earlier versions of aboriginal linux built with earlier kernels, you can
seach the repository history at http://landley.net/hg/aboriginal for
those, and their corresponding patch stacks.

For x86_64, you shouldn't need most of the patches. The main ones it
won't build without are the perl removal patches, because perl isn't
part of the build environment.

The description in the old presentation is still reasonably accurate:
http://speakerdeck.com/u/mirell/p/developing-for-non-x86-targets-using-qemu

You can also just do "HOST_EXTRA=perl ./host-tools.sh" (I.E. export the
environment variable and run the command), and it'll pass through perl
from the host environment so the kernel builds without patches. (Perl
showed up as a requirement in 2.6.25 and I finally got it to go away
again here:

  http://landley.net/notes-2013.html#18-05-2013

(But you still need the bc patch for reasons explained there, or you can
do HOST_EXTRA=bc (and if you need both, HOST_EXTRA="perl bc").)

> My questions:
> - considering only x86_64 target builds, can I simply ignore those
> patches? How safe it is to assume it will create a working image?

The kernel patches are mostly only needed to build the kernel. If you've
got a kernel, life is good. Userspace is generally fairly flexible.
(Occasionally uClibc has needed a patch to /usr/include/linux or
similar. You can actually _read_ sources/patches/linux-*.patch, each one
should have a description at the top.)

> - should I build glibc for such old build? How hard would that be?
> - any timeline on musl libc?

I was actualy working on the musl wrapper earlier today. I sort of gave
myself heatstroke on friday (more the "rehydrating by chugging an energy
drink" than the actual dehydration; the blood pressure drop when those
suddenly wear off in those circumstances is _scary_. My fingernails
turned blue and I felt like I had food poisoning.)

So this weekend was slighlty less productive than it could have been.
And my attempt to do a more coherent, better organized version of my
"rise and fall of copyleft" talk from ohio linuxfest... wasn't.

Still, recovering now, trying to catch up. Found out that the uClibc I'm
building doesn't have posix_fallocate (which is from posix 2001) so
toybox defconfig build breaks because fallocate is in there now (since
the function it needs has been in the standard for 13 years now), but
it's only present in uClibc if the config symbol
UCLIBC_HAS_ADVANCED_REALTIME is enabled. (*boggle* What does
preallocating disk space have to do with advanced realtime?)

That symbol is _enabled_ in sources/baseconfig-uClibc but not taking
effect for some reason. I suppose I'll track it down this weekend or
something, but in the meantime: excuse to poke at musl conversion.

Backstory on said conversion is here:

http://lists.landley.net/pipermail/aboriginal-landley.net/2014-May/001396.html

Rob

 1402976233.0