TheOldFellow wrote:
> I must start by saying that I have not been interested enough in this
thread to have read every contribution in detail.
Having built a couple of POX86S (plain old X86 system) with cross-lfs
instructions, I've decided to take a copy of the latest svn
non-cross-lfs book and maintain that for myself. The increased
complexity of the cross-lfs method has zero benefit in x86 AFAICS.
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.
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.
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.
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?
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.
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.
--
JH
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
