Ch5: "Locking in" glibc, Ch6: Adjusting toolchain
joorava at pcu.helsinki.fi
Mon Jun 2 11:38:19 PDT 2003
On Mon, 2 Jun 2003, Tushar Teredesai wrote:
> Have you checked whether the specs files with your procedure and the
> book's procedure are identical?
Thanks; you made me dig deeper.
At least on Intel platform "gcc pass 1" and "gcc pass 2" produce
an identical specs file; my procedure produces identical output
to the book's procedure.
* Compiled both passes as in the book from gcc-3.2.3.tar.
* Compiled pass1 from gcc-core-3.2.3.tar and pass2 from
gcc-3.2.3.tar. Specs identical.
However, my procedure assumes that the same applies to all other
platforms too, so I would not put it in the book.
However, the current implementation is flawed, also:
Right now, the first time the spec file is modified, is in
'"Locking in" glibc' step, where the sed modifies the gcc linker path
(in the spec file) by prepending /stage1 to it.
A couple of packages later, in 'gcc pass 2', gcc sources are patched
with the gcc-3.2.3-specs-4 patch, again to prepend /stage1
to the linker path. The patch is large because this time
the change is done to the gcc source tree, affecting all
platforms. The configuration differs a lot from 'gcc pass 1', too.
(And the question is, can we rely on this pass to produce an identical
spec file, or not?)
Finally, in Chapter 6, after compiling glibc, we modify the
spec file by reversing the sed in the '"Locking in" glibc' step
from Chapter 5. But, Tushar is right: it is the spec file from
'gcc pass 2' we run it on, not the original 'gcc pass 1' spec file.
Comparing the sed scripts to the gcc specs-4 patch,
it looks like the sed scripts only support some of the platforms
modified by the gcc specs-4 patch. They *should* be in sync.
As it is, I don't think LFS cvs builds on m68k or most 64-bit
platforms, as the sed scripts don't support /lib/elf, /lib64/lf,
or /lib/ld64 linker path variants - and there may be more;
even the patch does not modify the linker path for all platforms.
All this linker path modification magic would be better
handled by a tool script, I say.
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev