Lessons to be learnt from recent events

Jack Brown jbrown at kmts.ca
Tue Jan 28 21:22:59 PST 2003

On Tue, 28 Jan 2003 21:58:23 -0600, Greg Schafer wrote:

>> Aside from the current binutils/gcc problem, exactly what else is wrong
>> with the current method that doesn't result in a correctly built
>> toolchain?
> There is simply just too much that can go wrong. Witness the plethora of
> waffle re recent "libnss" and "build glibc twice" threads on the list.
> The whole thing needs a bit of a rethink to make it more robust and less
> error prone and thus more "future proof", which is what we are working
> towards. Best for me not to say any more until we have it all sorted.
> Less words, more action! :-)
> Greg
Lately I've been using a method similar to what needs to be done when
crosscompiling an install od GNU/Hurd from a Linux install. (or if you
prefer cross compiling a Linux installation from FreeBSD or something
similar). I feel it has a fair bit of potential and has the benifit that
the method should be capable of working from almost any POSIX type host.
(Imagine being able to build LFS from a copy of WinXP/Cygwin).  I also am
currently hammering out my method as well.

The bare bones of it is to build a functioning toolchain using the (new)
packages desired, then using that toolchain to install a fresh version of
itself to a target partition using DESTDIR (or similar tools).  An easy
way to visualize the effect is to think of making a normal base LFS
system then rebuilding all the packages from chapter6 but use DESTDIR to
drop the results onto a fresh partition. in this way all resulting
packages are built using the same version of them selves and problems
like "Perl before Glibc" evaporate. the current scripts I'm using can
nest a fresh LFS within a fresh within a fresh LFS esentially eliminating
any possible contamination from the host system.

There is slightly more to it than what I have said (eg Perl doesent like
DESTDIR, so I build that within the enviroment before DESTDIRing the
other packages then build perl first thing after chrooting into the new
environment, though all the packages already on that partition will have
been compiled using a dynamically linked Perl residing in exactly the
same path as the one about to be compiled) Even so it is perhaps easier
than you might think reading my shoddy description

Jack Brown

(incidentally I think that's why I forgt all about the --with-ld=path
issue since using this method it's totally unnesary if you use the
scripts to recurse more than a level or two in before completing the
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list