On Tue, 12 Sep 2006, Dan Nicholson wrote:
On 9/12/06, Brandon Peirce <[EMAIL PROTECTED]> wrote:
Dan Nicholson wrote:
>The advice at the end of Ch. 6 is bogus.
Would you care to elaborate? Thx
A long standing hammering of /tools done in the toolchain readjustment.
When you finish Ch. 5, /tools is well fleshed out and the toolchain is
properly set to compile programs that link into /tools/lib, etc.
Then you get to the Ch. 6 readjustment and you change the default ld
(in /tools) and add a specs file (in /tools) so that compiled programs
will link to /lib, etc. in the chroot. This achieves the proper effect
as you don't want your final gcc and binutils linking against the
temporary system.
However, when you get to the end of Ch. 6, it says you can tar up
/tools and use it again. Wrong.
Sorry, I couldn't find that bogus advice, which is why I asked.
Going through the museum, I see it got ripped out the book after 6.0.
Now your toolchain in /tools points to
/lib and friends. If you move the old ld back in /tools/bin and remove
the specs file, all is well. Then you really can unpack /tools and
start firing away in Ch. 6 on a blank disk.
The way it is now, a tarred up /tools provides nice temporary tools if
something is messed up, but it doesn't give you a clean starting point
if you were trying to build a pure final system.
So end of Ch 5 would be the good place to tar up /tools then,
instead of end ch 6, right?
The changes in /tools to adjust the toolchain are not really
necessary. There are other methods where the changes could be made
without affecting anything in /tools (beware of flame wars, though :).
See how DIY does the readjustment and subsequent gcc and binutils
builds:
http://www.diy-linux.org/x86-reference-build/chroot.html#c-readjust-toolchain
Well that's not so different from LFS, hardly more than a syntactic
difference!
As far as I can tell without reading cover-cover, it's still the same "pure
LFS"
idea of constructing a temp toolchain in a chroot env, then using it to
build the
final toolchain and switch over to that to build the rest of the system.
They just
use a temp specs file instead of modifying the installed one.
Is that wording OK to avoid flame wars? :)
BTW I'm interested in taking this subject further (not to suggest LFS should
do it differently, but to discuss/validate another alternative that I'm
developing). Something to better carry across to lfs-chat maybe?
Brandon.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/lfs/faq.html
Unsubscribe: See the above information page
