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

[Andrew Bradford]

On 10/01/2014 04:41 PM, Andrew Bradford wrote:
> 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.

One downside would be that for the target file system, since I propose
using gcc's --sysroot= switch, there will be a bunch of header files and
static libs built and installed along with shared libs (for libraries,
at least).  In the final actual target file system, likely all anyone
really needs is the shared libs and any actual executables.  Having
headers and static libs in the final target file system is wasteful of
space.

Before deploying the target file system the headers and static libs can
be deleted, such as during tarring up of the target file system, but
you'd want to make sure you kept them around in case later you wanted to
build another package that needed some headers/libs.

This must be a solved problem, I just don't know the solution, yet.  I'm
certainly not the first person to be concerned with this.

Thanks,
Andrew