On Monday 10 December 2007, Chris Staub wrote:
> Ivan Kabaivanov wrote:
> > Hi all,
> >
> > I believe there's a untriggered bug in chapter 6, Re-adjusting the
> > toolchain.
> >
> > We've just entered the chroot, installed the kernel headers and built
> > glibc. At this point we still only have /tools/bin/gcc. We've just built
> > glibc so we have it under /lib.
> >
> > Now we re-adjust the gcc (the /tools gcc, note) specs to use the newly
> > built linker.
> >
> > This is the code:
> >
> > gcc -dumpspecs | sed \
> > -e 's@/tools/lib/ld-linux.so.2@/lib/[EMAIL PROTECTED]' \
> > -e '/\*startfile_prefix_spec:/{n;[EMAIL PROTECTED]@/usr/lib/ @}' \
> > -e '/\*cpp:/{n;[EMAIL PROTECTED]@ -isystem /usr/[EMAIL PROTECTED]' > \
> > `dirname $(gcc --print-libgcc-file-name)`/specs
> >
> > this expands to /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs (LFS-6.3)
> >
> > So far, so (kinda) good, and still the problem is not triggered.
> >
> > Then we go on building the rest of Chapter 6. If this is all you ever
> > use /tools for, and I'd say about 98% of the people building LFS do just
> > that, you're ok.
> >
> > Now, I remember reading in the book that /tools could be kept in case you
> > want to build more instances of LFS. I quickly scanned the LFS-6.3 but
> > couldn't find the text. Maybe it was in an older book and has been
> > removed since. But this is what we do for ipcop, we pack up /tools for
> > speeding up future rebuilds.
> >
> > Suppose you do want to use /tools to build another LFS and you tar it up
> > (just /mnt/lfs/tools, not the rest in /mnt/lfs) and you unpack it on a
> > new host and you chroot into it:
> >
> > So, we should not overwrite the /tools gcc specs in Chapter 6, but keep a
> > copy of it in, say, /tools/lib/gcc/i686-pc-linux-gnu/4.1.2/specs-tools
> > and rename it back after we build gcc in Chapter 6. Then we can
> > guarantee that /tools is self-sufficient. Maybe we should do a pass 2 of
> > the readjustment in Chapter 6. This is what I'll do for ipcop, but if
> > you come up with a better solution, I'd rather stick with LFS book.
> >
> > IvanK.
>
> 1. The gcc in /tools, built in GCC pass 2, should be linking to /tools
> by default anyway, so if you want to re-use /tools after re-adjusting
> the toolchain you shouldn't have to do anything with the specs file
> other than removing it.
>
> 2. The other problem is that the linker has also been modified, so you'd
> also have to reverse the commands to switch /tools/bin/ld and ld-new.
>
> 3. There is a warning about this in both 6.3 and dev LFS books, on the
> "Changing Ownership" page at the end of chapter 5...
>
> http://www.linuxfromscratch.org/lfs/view/development/chapter05/changingowne
>r.html
>
> Caution
>
> If you intend to keep the temporary tools for use in building future LFS
> systems, now is the time to back them up. Subsequent commands in chapter
> 6 will alter the tools currently in place, rendering them useless for
> future builds.
Chris,
so that's where the text was -- my memory had selectively remembered the part
about using /tools for future builds and blocked the text about chapter6
altering /tools.
Sorry for sounding the alarm without merit :-)
Thanks,
IvanK.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
