An idea: isolate libs [was: Pure LFS]

Steve Martin srm at netcomuk.co.uk
Fri Feb 7 15:11:36 PST 2003


On Thu, 2003-02-06 at 22:53, Jack Brown wrote:
>snip< 
>   Based on what I've been personally doing, I've been finding that the
> resulting files (from compilation) stop changin around the third
> iteration, if you use static linking for the first step. I'm curious to
> see how the hint affects this..  Also I haven't spent much time running
> make checks yet.
> 
>   As I mentioned before one thing I prefer about starting
> from static binaries and then just going ahead and making a second build
> of the dynamic toolchain (using the first dynamic toolchain) is that the
> instructions wind up being brutally simple, and don't in any way involve
> trying to link to libraries residing in non standard locations or doing
> anything to stop compilations from just accepting the location that they
> find related files in at face value.
> 
I have attached a little doc which attempts to explain the magic number
3 iterations; I think that clarifies why 3 iterations are necessary and
why a gcc bootstrap takes 3 passes.  I would suggest, based on my
current tests, that bootstrapping the gcc builds in the purity hint is
unnecessary.

I am currently working on a build which does not require the use of
mount --bind, and it hasn't needed any tricks not already employed in
the hint.  I am of the opinion that it should be possible to build a
complete LFS without any need to chroot, effectively removing the
current chapter 5 (don't shoot me!) this is something I'm playing with
right now; if I get positive results I will report them back here.

-- 
Steve Martin <srm at netcomuk.co.uk>

Still can't think of anything witty to write here.
-------------- next part --------------
Acheiving 'Purity'
==================

We have three toolchain elements: binutils, gcc and glibc; our aim is
to produce 'pure' versions of each tool.  This actually requires an
exhaustive bootstrapping process which we will try to illuminate
below.  Anyone interested in a more focused view of the operations
decribed should take a look at 'Compilers: Principles, Techniques, and
Tools' by Aho, Sethi, and Ullman.

First a definition of a 'pure' toolchain: a pure toolchain is one in
which each component has been produced by pure components of that
toolchain. To keep things simple we will give each component a single
letter representation and discuss each part in terms of its
components.  Confused?

Let us call the host binutils 'a', gcc 'b', and glibc 'c' (the actual
versions are not important to this exercise), we will refer to the
target binutils as 'X', gcc 'Y', and glibc 'Z'.  Each individual
component will be referenced by its components, so the host binutils
will be referenced as 'abc'; this says that binutils 'a' was compiled
by gcc 'b' against glibc 'c'.  Our pure binutils will be 'XYZ'; that
is, binutils 'X' was compiled by gcc 'Y' against glibc 'Z'.  Please
take a moment to grasp this referencing; it will make things easier as
we proceed.

Pass 1
------
Binutils 'X' is produced using binutils 'abc', gcc 'bac' and glibc
'cba' producing binutils 'Xbc'.

Gcc 'Y' is produced using binutils 'Xbc', gcc 'bac', and glibc 'cba'
producing gcc 'YXc'.

Glibc 'Z' is produced using binutils 'Xbc' and gcc 'YXc' producing glibc
'ZYX'.

At this point it looks like glibc is 'pure', but it was produced using
impure tools.

Pass 2
------
Binutils 'X' is produced using 'Xbc', 'YXc' and 'ZYX' producing 'XYZ'.
Gcc 'Y' is produced using 'XYZ', 'YXc' and 'ZYX' producing 'YXZ'.
Glibc 'Z' is produced using 'XYZ' and 'YXZ' producing 'ZYX'.

Everything now looks 'pure', but 'X' and 'Y' were produced using
impure tools.

Pass 3
------
Binutils 'X' is produced using 'XYZ', 'YXZ' and 'ZYX' producing 'XYZ'.
Gcc 'Y' is produced using 'XYZ', 'YXZ' and 'ZYX' producing 'YXZ'.
Glibc 'Z' is produced using 'XYZ' and 'YXZ' producing 'ZYX'.

Finally we can be sure that the toolchain is 'pure'.

**NOTE: This procedure also negates any necessity to use 'make
  bootstrap' on gcc.


More information about the lfs-dev mailing list