[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
access.
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
http;//landley.net/aboriginal/control-images/downloads/binaries/lfs-bootstrap.hdc)
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...)
Rob
1382974495.0
More information about the Aboriginal
mailing list