An idea: isolate libs [was: Pure LFS]

Jack Brown jbrown at kmts.ca
Sun Feb 9 18:00:59 PST 2003


On Sun, 09 Feb 2003 18:02:24 -0600, Rui Ferreira wrote:

> Jack Brown wrote:
> 
>> I like the fact that this produces a 100% self hosted toolchain. all
>> "dynamicly linked and installed into their final location packages
>> which were compiled by the sameversion of them selves" are compiled by
>> "dynamicly linked and installed into their final location packages
>> which were compiled by the sameversion of them selves"
>> 
>> I can't really see where this would have any pitfalls, with the one
>> possible exception of the kernel ABI inported into the chrot
>> environment
> 
> Where is this better then the old way of just make lfs twice? - Use the
> host system to build lfs1
> - boot lfs1
> - Use lfs1 to build lfs2
> - Keep lfs2
> 
> In the final system we have packages that have been compiled 4 times, 3
> of which were with the exact same version.
> 
> 
> I think that this is all about reaching purity with the minimum required
> efford.
> If we can stablish that the only packages that need to be pure to
> produce a pure system are binutils, gcc and glibc, then, we'll not need
> to compile anything else - just work with their static versions all the
> way. And also, how and how many times do they need to bootstrap (the
> toolchain).
 
there's really only a few differences:

1. since the static binaries are placed into the filesystem in their
normal locations, any compilations that detect the location of other
programs would find themin their normal locations and hardcode the
correct path without any intervention (man is the main culprit and
currently I'm not even building it until after having booted the system,
but one of my goals was to "future proof" the method.  for instance
coreutils, just to pull a name out of a hat, may not do this _now__ but
even if at some piint it started to do this type of thing we would be
imune)

2. by using a 3rd build the final dynamic binaries were built using
dynamic binaries insead of static ones and all dynamic libraries were
present before even the first package was compiled.  If you're comfortable
without this then just go ahead and skip stage 3 and you'll end up with a
system more or less equivalent to the current LFS but still with the
other benifits I'm mentioning here. Note this basically coresponds to the
benifits of using Greg and Ryan's new method but does so in a way which
is much simpler and does not introduce any further gotchas, by contrast
it removes many former gotchas. (ie. things like
"--with-ld=/lfs/static/bin/ld" or "cross-compiling = no" become
completely irrelevant and unnessary)

3.  It creates alogical seperation between the core packages needed for
building software and what's needed for making the system boot. more or
less an educational thing.

4. by using DESTDIR= in this manner it becomes possible to use the
stage2/3 instructions ina completely unchanged form to replicate a
completed LFS system in one single step.  in fact if you are using a LFS
system which differs only slightly interms or package versions, for
instance one you build previously with gcc 3.2, then it's probably ok to
just just begin with stage2 or stage 3.

Jack Brown

Again in someways the point was that it is not a large departure from what
we currently do, it just improves upon it.
-- 
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