[Clfs-dev] Embedded cross-tools then build target fs question

[Andrew Bradford]

Today's embedded book builds the static GCC and places it into
${CLFS}/cross-tools, then builds musl libc and places it into
${CLFS}/cross-tools/${CLFS_TARGET} which is the sysroot, and finally
builds GCC again and places it into ${CLFS}/cross-tools.

So the result is that you have a cross compiler (binutils and gcc)
living outside of the effective sysroot but the libc living inside the
sysroot.

This seems to mean that if you delete your target file system (the
sysroot) that you're going to have to build musl libc again and possibly
build gcc-final again or somehow deal with gcc-final not being able to
find its libc or being subtly broken.

Would a better idea be to build gcc-static, musl libc, and gcc-final
into ${CLFS}/cross-tools with that directory being the sysroot and then
go and build all the actual target portion (libgcc (again), musl libc
(again), busybox, etc) as a part of section 5 "Installing Basic System
Software"?

In this way, so long as the libgcc and musl libc are built without any
changes from their configuration in gcc-final and the initial musl libc
build, you should be able to fully delete the target root fs and start
over without having to build the toolchain again.  Right?

This should mean that when building things for the target that gcc's
--sysroot= option will have to be passed as a part of ${CC} so that gcc
can find the target libraries and headers.  But this shouldn't be a huge
deal as we set the CC variable anyway and store it in .bashrc for the
clfs user.

I think the only reason the existing book puts the libc into the sysroot
but gcc not in the sysroot is because this is how the main book does it
for building the temporary system which is booted/chrooted into in order
to create the final system.  This isn't a problem for the main book as
the temporary system is only used once, while for embedded you may want
to blow away the target root fs and then build it again since the target
doesn't have a toolchain on it.

Would this work?

I've not tried it, yet, but I expect to run into something strange with
libgcc as past experience with libgcc has shown that I don't fully
understand it.  I believe musl won't mind and that this should actually
fix the bug where gcc-final ends up deleting the symlink to the musl loader.

Thanks,
Andrew