Lessons to be learnt from recent events

Greg Schafer gschafer at zip.com.au
Wed Jan 29 16:21:51 PST 2003


On Wed, Jan 29, 2003 at 03:00:48AM -0700, Gerard Beekmans wrote:
> On January 29, 2003 02:51 am, Ryan.Oliver at pha.com.au wrote:
> > >The spec file would be best - its meant for making those kind of changes.
> >
> > Probably, but I don't want to have to write the sed for that :-)
> 
> Patch file? I know more work but a cleaner solution, and maybe even easier to 
> understand and change.
> 
> > We'll get something a bit more meaningful to you guys soonish ;-)
> 
> Looking forward to it with great anticipation.

Ok, it seems there is a fair bit of interest afterall.

Unfortunately, I need to eat, and to eat I need to earn bucks, and this is
really getting in the way of LFS hacking :-)

I've attached the draft hint intro that we wrote which might give interested
folk some clarity about all this stuff.

The reason for the hint suggestion is this is a fairly drastic change and I
figured it would be best to let it bed down in a hint (much like MSB did
with his keep separate hint) before trying to get it into the book.

Greg
-------------- next part --------------
TITLE:		How to build a "pure" LFS
LFS VERSION:	CVS
AUTHOR:		Ryan Oliver <Ryan.Oliver at pha.com.au>,
		Greg Schafer <gschafer at zip.com.au>

SYNOPSIS:
	The current LFS build method is a lot better than it used to be but is
still somewhat flawed in that not enough emphasis is placed on building a
correct tool chain. This was recently highlighted by criticism levelled at LFS
from senior Linux kernel hacker Alan Cox on the kernel mailing list. Here we
will present a new strategy aimed at building a correct tool chain and thus a
"pure" LFS system. It is our belief that building a correct tool chain is the
single most important lesson that people reading the LFS book need to know.
Everything else is secondary.

HINT:

CHANGELOG
=========

  * 2003-XX-XX  Initial revision

INTRODUCTION
============

Broadly speaking, the tool chain comprises binutils, gcc and glibc. As of this
writing, the current LFS version is 4.0. The problems with the build method as
used in this version can be summarised as follows:-

  * too reliant on the host (build) system
    e.g. the autoconf tests for the static tools are performed whilst looking at
    the host system which may be vastly different from the final system. The
    most widely documented and glaring manifestation of this problem is gcc
    which ends up miscompiling a portion of glibc due to this flaw.

  * too much code is brought in from the host system
    e.g. all the static tools are statically linked against the host's glibc.
    The host's glibc is an unknown quantity and may contain bugs or anything.

  * too susceptible to incompatible glibc changes
    e.g. statically linked binaries compiled on a glibc-2.2.x based system that
    contain calls to getpwuid() crash when run on a glibc-2.3.x based system.

  * glibc is compiled whilst no existing glibc is present
    e.g. the glibc autoconf tests produce different results depending on whether
    an existing glibc is found or not. This leads to inconsistencies and
    encourages hacks and workarounds.

(NOTE - some of the abovementioned issues have been partially addressed in the
CVS version of the book but still do not go far enough and leave too much room
for error.)

To overcome all the issues, a new approach is required. The essence of what is
presented below can be summarised as follows:-

  * build a fully "self contained" and "self hosting" tool chain that has no
    dependencies on the host system.

The key differences between this approach and current LFS are:-

  * a glibc is built in Chapter 5

  * this glibc is built using the Chapter 5 gcc and binutils (NOT the versions
    from the host)

  * the rest of Chapter 5 is built against the new glibc using the new binutils
    and gcc

Some of the advantages to doing it this way are:-

  * we can build everything shared. It isn't necessary that we build all our
    binaries static in Chapter 5 (though you still can if you want to) as we
    will still have access to the shared libs we create when we chroot.

  * everything we use to build our shared binaries and libraries in Chapter 6
    will ALREADY be built and linked against the glibc we are migrating to. This
    avoids glibc migration issues now and in the future.

The technical highlights of how the new approach works are:-

  * careful manipulation of ld's linker scripts (in particular, the SEARCH_DIR
    variables)

  * simple editing of gcc's "specs" file to tell gcc which dynamic linker to
    produce executables for

  * clever use of mount's "--bind" option to play a few filesystem tricks


PROCEDURE
=========

<insert details here>


More information about the lfs-dev mailing list