SVN-20070706: Step 5.7 Adjusting the Toolchain
craigmjackson at gmail.com
Fri Jul 13 21:26:40 PDT 2007
> Um, you seem to be talking as if one must run a 64-bit OS on 64-bit
> hardware. That is, of course, utterly ridiculous. IMHO 32-bit OS'es
> running on 64-bit hardware are still the norm. See this recent post from
> an Intel employee for example:
I'm not implying that, in fact i completely agree with you. I am
merely speaking to some of the reason the I personally felt compelled
to switch. LFS is primarily educational for me, until the point when
I am using it in a production environment (which is not now). :) With
this education comes a desire to stay up-to-date, rather than just
build the most stable OS possible (I would use LFS 5 if that were the
> Not only that, you also seem to be implying the days of the LFS *build
> method* are limited. I might be biased but I can assure you that the basic
> idea of the LFS/DIY build method works fine on x86, ppc and x86_64 for
> *NATIVE* building of Glibc based systems and that it has stood the test of
> time. Of course, it doesn't cope with multilib nor x86 -> x86_64
> bootstraps but that is where cross compilation comes in handy. I will not
> go into the many drawbacks of cross versus native because it's all been
> said before.
No I don't have issue with the LFS build method. All the (x)lfs
projects use this method to some extent, and it is one that I like
more and more after each successful build. It is very easy to
understand and cannot be much simpler when building toolchain packages
etc. This is a great idea and the fact that CLFS is so remarkably
similar is a testament to LFS's proven concept. I am not writing this
to whine and complain, it truly saddens me to think that two groups of
like minded people completely split because of a detail such as this.
I just hope that when users and testers start migrating to CLFS more
and more, which is inevitable, that the LFS work performed since the
fork will not be in vain, and that the hundreds of thousands of hours
of learning and development by the LFS devs will not be in vain.
> I agree with Dan. It's probably time to implement a native non-multilib
> x86_64 build as an option for LFS. But to keep everything compatible with
> x86, you'll probably need the lib -> lib64 symlinks which mirrors the
> practice of some distros and also what I've done in the DIY Refbuild.
I have no "loyalties" to either group. I work on whatever project
suits my purposes at any moment. If the LFS project started to make
native 64 or multilib builds, I would bet that the shear maturity of
the LFS project would win most of the users of CLFS right back.
Stylisticly, and for stability's and compatibility's sake, I actually
prefer LFS to CLFS. Functionally, CLFS is more progressive, and I am
a progressive user, as most people who try any LFS are naturally
progressive users as well.
More information about the lfs-dev