Jeremy Huntwork wrote:
> Increased complexity? For x86 -> x86, I'm not sure I see it that way.
> Let's break it down a bit. In the 5.x-6.x books, chapter 5, for your
> toolchain, you built gcc 4 times, right? (static build we run 'make
> bootstrap' with is more or less equal to 3 builds of gcc) Now, we build
> it 4 times total again before we start on the final system (two of the
> times slightly quicker builds because we're using the 'make all-gcc'
> command). Binutils is built the same amount of times, and the two extra
> glibc steps (the headers and the startfiles) are really minimalistic in
> their impact. All in all, from cross-tools to the end of the
> temp-system, you have pretty nearly the same amount of work you would do
> in chapter 5 now.
My main concern is the increased use of patches and seds to change
things from the intentions of the package authorities. Some of them are
real 'hacks' - I feel the same way about the specfile edits from PLFS
BTW. This is what I mean by complexity. And the strict separation is
not really needed if the build platform is your LiveCD. Indeed, if we
are going to be pedantic about seperation, then we should build MORE
tools BEFORE we build the cross-tools set, otherwise we have never run a
gcc with --bootstrap for the host (you can't bootstrap a cross-build).
> If you mean complexity because it's a new method of building, well the
> reasons for all of the steps will be fully explained before any book is
> finally released. I can't see how two extra variables ${LFS_HOST}, and
> ${LFS_TARGET} used in two new flags, --host or --target provide that
> much more of a complexity layer.
With respect, I think I understand the method now, not that most newbies
will even bother to read your explanations before flooding the wrong list.
> And, again, the reason for going this route even for just x86 -> x86
> would be to provide absolute independance from the host. Isn't that what
> LFS has been aiming for since the beginning of PLFS? This is in a sense
> the realization of that goal. Total abstraction.
We all might find it refreshing to have another look at LFS 2.4 - it
built a mean Linux - of course it had hidden faults, but it worked very
well.
>> I'm not saying that cross-lfs isn't a great bit of work, it's just that
>> I don't see that it has any application to 95% of folk building LFS for
>> the first time, and the 5% who need a cross method could reasonably read
>> a hint.
>
>
> I think by this argument, we could just revert the current book to drop
> the entire PLFS method (all of chapter 5) and just build LFS the way it
> used to be. What's the point of trying to separate the final system
> from the host, if you're not concerned about getting it entirely clean?
Yes, and that would be fine if we always built (on x86) from a LiveCD of
the latest toolchain. It's certainly quicker and less error prone.
> BTW, I wonder if the 5% comes from the fact that up to now, LFS only
> supported x86. There are actually quite a large number of people using
> Linux on other archs, and if we support those, the number of LFSers
> total can only grow. Not to mention that the AMD64 is becoming *very*
> popular these days, esp., from what I can see, among LFSers. There is
> definitely a bigger need than just 5%, or at least, there soon will be.
This is a good point. We'll see if the stats reflect this - we should
prepare the website to take 'warranty-cards' perhaps?
> Anyway, I've done the build several times now, and quite honestly
> (especially once the reasons for each step are fully layed out) I don't
> see that the cross-lfs book would be much more complex than the separate
> tools idea that we are using now.
Me too - several builds, one from Gentoo (up-to-date ~x86) and one from
Ubuntu HH. Both work OK, and I've built most of BLFS on one of them
with only minor issues (mind you, my BLFS built without big problems on
DIY-linux-gcc4 too). I just had the impression that I was typing more
maybe ( Real LFSers don't use scripts )
We often (once a year or so) have a debate in LFS circles to decide if
those who want to try experimental stuff should be in the forefront, or
whether we should be trying to get a perfect book for newbies to build
with. The answer is a compromise, always was, always will be. I'm
usually with the bleeding-edgers - I'm just not sure that the balance is
right on this one yet.
R.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
