[Aboriginal] toolchain placement options

Rob Landley rob at landley.net
Mon Oct 28 08:34:55 PDT 2013

Sorry for the late answer. Started a new job last monday and I was  
behind on my email before that...

On 10/18/2013 04:32:45 PM, Eric Laganowski wrote:
> Hello,
>  First I want to thank everyone involved in the Aboriginal Linux for
> their hard work implementing something that it seems few got right:  
> the
> elimination of the cross compilation for the packages. I was playing
> with LFS for about a decade now from time to time and was also playing
> with various other build systems: Gentoo, OpenWRT and recently
> Openembedded/Yocto. I was quite excited about OE until I decided to  
> try
> to port some packages to it. After some frustrations, I composed a
> proper web search query and landed on Aborigianl Linux website :)

Thanks. (It's hard to describe what the project does in a way people  
can find it without already knowing what they're looking for.)

> I have a general question about the philosophy of AL: coming from LFS,
> it seems that what AL is doing before launching QEMU is building a
> native "host-independent" toolchain (in LFS terminology).

That's one of the stages, yes. We'd happily use other people's  
toolchains (it's designed to be modular), but nobody else provides  
prebuilt binary _native_ toolchains, and we need those too. If our  
setup doesn't support a microblaze cross compiler, it probably won't  
support a microblaze native compiler, so using somebody else's cross  
compiler doesn't buy us much... :(

> LFS builds the
> toolchain under /tools, which means it is easy to discard it  
> afterwards.
> Why doesn't AL follow the following procedure?

Do you mean /tools on the host system? Because writing to that would  
require root access, and nothing that runs on the host requires root  

Do you mean in the system image? I did that for a while (commit 782  
changed "NATIVE_TOOLS" directory to "ROOT_NODIRS"the last vestige of it  
was removed by commit http://landley.net/hg/aboriginal/rev/1411 , see  
also 1272, 783, and so on...) but it was confusing to explain and  
tended to be brittle.

When the default rootfilesystem became squashfs (meaning you can run  
multiple emulator instances from the same root filesystem at once,  
don't have to worry about fsck, don't have to figure out how much extra  
writeable space to preallocate...), creating a new image involved  
populating a chroot directory under /home (which could be started with  
a snapshot of the current one, see the lfs-bootstrap.hdc image for an  
example, either at http://landley.net/hg/control-images or  
was the way to go, so having stuff in /tools on the original filesystem  
didn't help anymore.

> Essentially what I want
> is to build my own C library under nat ive buil d and link everything
> against it, instead of linking against uClibc that is shipped by AL. I
> am yet unsure on how easy this would be, provided that C library is
> under /lib and not under /tools/lib.

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.

It's still fiddly system building, but at least it's _native_ fiddly  
system building. I.E. you can follow linux from scratch mostly at that  
point, if you want. (modulo needing to use /home/tools instead of  
/tools because the root filesystem is squashfs and thus not writeable.  
If you want a writeable ext2 root filesystem you can set  
SYSIMAGE_TYPE=ext2 before running build.sh (either by modifying  
"config" or exporting it as an enviornment variable) and it'll produce  
one, and you'll probably want to set SYSIMAGE_HDA_MEGS as well. Or just  
look at the lfs-bootstrap.hdc image to use as an example, the  
native-build.sh script mounts it on /mnt and runs /mnt/init instead of  
providing a shell prompt. (Hit space when it prompts you to get a shell  
prompt anyway, that's an easy way to poke around in it. That's how I  
debug the native builds...)


More information about the Aboriginal mailing list