[Aboriginal] toolchain placement options

[Rob Landley]

On 11/07/2013 05:41:57 PM, Eric Laganowski wrote:
> > I'm trying to convert aboriginal over to use musl-libc
> 
> > Natively, if you want to use a different libc the most obvious
> approach
> > is to build a chroot that uses it. Start by installing your new
> > toolchain in a directory under /home in the system iamge (which
> > dev-environment.sh attaches a 2 gigabyte hdb.img ext3 image to by
> > default, so it' s writeable and potentially persistent), then use  
> that
> > toolchain to build more stuff.
> 
> I guess I can more or less follow the LFS approach in native stage,
> though
> I will need to satisfy LFS "host system requirements" by building  
> Perl,
> Texinfo, etc and then start building what LFS calls "Temporary  
> System".

I pointed you at  
http://landley.net/aboriginal/control-images/lfs-bootstrap.hdc right?

I've already got an automated thing that does this, and I usually  
upload the resulting images when I do a release, somewhere under:

   http://landley.net/aboriginal/downloads/binaries/extras

> The thing is, however, is that this diminishes Aboriginal's value as a
> _build_
> system, as I can launch any target-specific distro under QEMU,  
> possibly
> with all pre-requisites already there and proceed with LFS stages in  
> the
> same or possibly even more convenient fashion.

The point of aboriginal linux is that it creates from scratch the  
simplest native build environment for an arbitrary target, in a  
reproducible way. It then provides some infrastructure to perform  
automated native builds within that, either on real hardware or under  
qemu.

One such piece of infrastructure is the lfs-bootstrap image, which I  
need to update to 7.4.

> I guess if you are not planning to develop Aboriginal in direction of  
> a
> flexible build system this is fine by me.

I'm not turning it into a full-fledged distro. what I want to do is  
create bootstrap images for distros, so you can do a debian-boostrap  
and gentoo-bootstrap and fedora-bootstrap and so on that create a  
chroot within which their build tools will run to add more packages,  
building them from source and loading them into their repository on  
whatever the host happens to be. So if you want to create "slackware on  
sh4", you can do so.

Alas, that turns out to be a big job (gentoo assumes it's building  
under gentoo, _and_ every ebuild file in portage is annotated with the  
complete list of every target it's allowed to run on, so adding a new  
target to the portage tree requires touching just about every ebuild  
file in the tree because they weren't THINKING...)

It's a todo item, but switching everything over to use toybox and musl  
and getting android self-hosting are higher priority todo items.

> Please let me know if I am missing something.
> 
> What I attempted to accomplish was to have Aboriginal provide me with  
> a
> native toolchain that can build the entire (possibly  
> embedded-targeting
> )
> system where I can use the C library of my choosing, or at least not  
> to
> depend on cross-compiled native C library.

Yes, that's definitely a goal of the project.

> I had some ideas on how to
> provide for packaging support (rpm or opkg) using AUFS (for which I  
> ship
> custom kernel to Aboriginal), but at this point I am stuck with the
> (almost)
> chicken and egg issue, and my cross-compilation/toolchain experience  
> is
> not
> enough to overcome them.

I'm working on getting musl working. Once I've done that I should go  
back and do "build a uClibc chroot under musl" and "build a glibc  
chroot under musl" bootstrap.hdc files.

> By the way, is there a way to checkout the most recent stable  
> Aboriginal
> revision that still supports the /tools hierarchy?

It would be something like 3 years old.

Look at /sbin/setup-chroot instead. (In the source it's  
sources/root-filesystem/sbin/setup-chroot I think.)

Rob
 1385592662.0