Planning for Cross-LFS/Multi-Architecture 7.x Release

TheOldFellow theoldfellow at
Tue Apr 19 07:16:09 PDT 2005

TheOldFellow wrote:

> Finally, a note about Ryan's scripts.  They are, no doubt, extremely
> clever.  This is the problem.  I will not expend the energy to
> understand someone elses complex script. 

Well, I decided I'd try anyway.  This is the result.  I find myself
completely baffled about HOW the cross compiler is built.  Can someone
point me at a (short) tutorial.


Anyway, for what it's worth:

The Ryan Oliver Cross-Built LFS Method.
A short introduction (just to see if I've got it)
By TheOldFellow 2005-04-19

What's all this then?

For the past year or so, since the Pure-LFS method of building the LFS
toolchain was invented by Ryan Oliver and Greg Shafer, Ryan has been
working on a new toolchain build method that works for situations where
the host machine and the target machine are of different architectures.
 Although Ryan has dropped a lot of hints along the way as to how this
all works, and even published his scripts, it's not clear, as I start to
write, at least, to me how every nuance behaves to achieve the
objectives.  So I thought that rather than moan about it, I'd write it up.
Hopefully, Ryan or someone else will tell me where I'm wrong, and add
the bits I've obviously not noticed.  Necessarily much of this is
plagiarism - I acknowledge everything I borrow as being the intellectual
property of it's originator.


The objectives of the method are as follows:

At no point do any host system headers or libraries pollute anything in
the new system, not even the temporary toolchain used to build the final

No reliance on the running kernel version while building the temporary
toolchain.  This means that the architecture of the running kernel can't
influence the result.

Separation of the host tools (i.e. initial compiler/binutils) which are
linked against the host system libraries from the tools that will be
used to produce the target system. That is, the  tools that are used to
build the target system are linked against a glibc built specially for
that purpose.

This separation means that there is no need to edit the specfiles or
interfere with the normal operation of the linker (as is done in the
current Pure-LFS derived LFS).

And there is no need for the keep binutils source directory around.
The method produces 2 separate toolchains early in the build, one is a
cross-compiler (use to build things on the host system for the target
system), the other is a target native compiler (which is used to build
the target system on the target system).  This also has the advantage
that it's possible to backtrack to solve problems, if, for instance, you
want to try a novel configuration option or a patch, or just to correct
a mistake.

It's possible to build  multi-lib targets from any host (or LiveCD).
For instance, building a bi-arch x86_64 from a x86_32 host.

But the major advance over the current method (Pure LFS) is that this
method supports cross-platform builds, uni-arch or multi-arch, and those
with difference glibc extensions, e.g. nptl or linuxthreads threading.


The method consists of a number of phases, each separate and self contained:

1.Building a good set of host tools.  It's important that the tools used
in the later stages can rely of the toolchain used to build them, so the
method starts by ensuring the versions and capabilities of the host
toolchain to be used.  These tools are help completely separately from
the host's own toolchain, and are built as an ordinary user.

2.Building a set of tools designed to run on the host producing code to
run on the target.  This is not just the cross-compiler, but is a fully
bootable system with the option to build extra facilities, such as
networking and ssl/ssh.  Of course, it's designed to boot on the target

3.Either having booted the system built in 2 above on the target
architecture, or having chrooted into it (of course, this later implies
that target=host), the final system is built using similar instructions
as in chapter 6 of the LFS book today.

Note, that each phase is self contained, only the output of the phase is
used in the subsequent phase, so if you discover a need in phase 3 for a
tool that you failed to build in phase 2, you can return easily to phase
2 and build it.


Phase 1 Building a consistent set of host compilation tools.

There are a number of  tools that are needed in Phase 2, and they must
perform as we expect them to.  The tools may or may not exist of the
host, and if they exist they might or might not be the versions we
require.  This simplest solution is to build a fresh set, using versions
known to have the correct properties.  Phase 2 can then be done with
this consistent set of tools higher in $PATH than the equivalents on the

The order of building is designed to minimise the possibility that the
host's libraries of include files will impact the tools.

The tools are built as an ordinary user, and none is built setuid etc..

Phase 2 Building a bootable system for the target system.

Now we have a complete and consistent set of host tools, we build a
cross-compilation system and then use that to build a bootable system
for the target architecture.  Note that the target architecture can be
the the hosts architecture, but it could also be something exotic, the
only requirement is that gcc supports it.

To build a cross compilation system we will need to use headers (include
files) that are appropriate for the target system.

1.Install a set of kernel headers for the target system's kernel.

2.Build binutils, adding the --host and --target configure options to
force configure to build a cross-compilation system (e.g. The linker
runs on the host, but expects object files in target format, and creates
executables for the target)

3.Install glibc headers by configuring glibc with --host and --build
options, sourcing the kernel headers and binutils tools from this phase
and then running:
 make install-headers

Then we add a set of headers for the threading library, since gcc needs
them for thread support.

4.Now we build the cross compiler gcc by passing the configure option
--host and --target.

I don't understand all the stuff about start files, and what about
specfiles ? - someone please help.  This must be the clever bit!

5.Finally we build a target glibc and then enough of a system to boot
using the cross compilation system we've just made.

Phase 3 Building a The target system on the target system.

Having booted the on target system, we use the toolchain built for the
target in Phase 2 to build a complete system.  The only deviation from
the current lfs book is to rebuild the ld executable as soon as a new
not-cross-compiled glibc is built.

More information about the lfs-dev mailing list