more on definitions

Mike Asher masher at
Tue Feb 3 09:19:08 PST 2004

----- Original Message ----- 
From: "weasel" <weasel at>
To: "LFS Support List" <lfs-support at>
Sent: Tuesday, February 03, 2004 11:50 AM
Subject: Re: more on definitions

> michael wrote:
> > I had the same kind of concern as Henry when going through LFS,and i
> > must say i still do not understand why the static linking at the
> > beginning of the toolchain build,since the code that will get included
> > will be the host's..ok,i get the idea of what is static and dynamic
> > linking,there's a separate linker for each case,right,but what makes you
> > decide between the two?I really think this should be better
> > explained,since it seems to lie at the heart of the LFS method..could
> > someone explain this as to a ten year old?Thanks,michael
> >
> Hi Michael,
> Ten?  Wow....keep at it!!!
> The reason that the ch5 tool chain is built staticly is so that once you
> are finished building it, you no longer need access to the host libs and
> the toolchain can stand on its own.  If you were to build this part
> dynamically then you would need these host libraries to be available
> during the build which is potentially dangerous.  Your host can files
> can be overwritten, your build process could inadvertently use files
> from your host system to build with.
> All of the reasons for this revolve around the idea of having a clean
> toolchain to build your LFS system with.  Its really a lengthy topic, if
> you search the LFS archives you will find a complete history (all most)
> of the "pure lfs"/"clean toolchain" saga.
> Nick
Just to add briefly to Nick's excellent summary, you don't "need" the static
linkage.  It is possible to do it dynamically.  Its merely far simpler (and
safer) to use a static linkage.  And, since the Chap. 5 chain is temporary,
the disadvantages of static linkage (code bloat) don't really apply.


More information about the lfs-support mailing list