On 3/14/07, Greg Schafer <[EMAIL PROTECTED]> wrote:
> Dan Nicholson wrote:
> >
> > One of the things that currently doesn't happen in the chroot
> > toolchain adjustment for LFS is making gcc prefer the new headers in
> > /usr/include. If you add '-v' to the sanity check output, you'll see
> > that it's still looking in /tools/include.
>
> Regardless of whether it fixes the ICA regression or not, this tweak
> should be considered for LFS because it fixes an outright bug in the build
> method.
>
> > Now I think I see the issue. We don't apply the glibc upstream patch
> > in Ch. 5. This patch touches two headers that may be included into
> > built sources: features.h and libio.h.
>
> That'd be it for sure. I wondered why I wasn't seeing the regression :-)
> If you keep the completed gcc build dirs, then diff them, it might
> give some more clues (not sure whether jhalfs allows you to keep build
> dirs). Whatever the case, IMHO it's a mistake to apply such a massive
> patch in only 1 phase.
As it turns out, I don't think this is causing the regression
directly. This is what I'm seeing right now.
So, I added each build tweak separately and together: patching ch. 5
glibc and adding -isystem /usr/include to the ch. 6 toolchain
adjustment. In all cases, the diff was still showing up.
Diving into it a bit further, it seems that in gcc-4.1.x, there is a
new build twist where the md5sum of cc1-dummy and cc1plus-dummy are
taken and then built into the real cc1 and cc1plus. A tiny program
called genchecksum in built in gcc/build which generates C files
cc1-checksum.c and cc1plus-checksum.c. This does not appear to be the
case with gcc-4.0.x.
So, the two checksums were different:
$ cat gcc-build-1/gcc/cc1-checksum.c
const unsigned char executable_checksum[16] = { 0x6d, 0x76, 0x77,
0x71, 0xfb, 0x6c, 0x18, 0x7f, 0x5c, 0xee, 0x74, 0x78, 0xc6, 0x8f,
0x95, 0x3b };
$ cat gcc-build-2/gcc/cc1-checksum.c
const unsigned char executable_checksum[16] = { 0xd6, 0xfe, 0x41,
0xe7, 0xc, 0x31, 0xb5, 0x3d, 0xf5, 0xc9, 0xca, 0xd3, 0x84, 0x6d, 0x6,
0x7 };
However, after stripping the symbols from cc1-dummy in both runs (as
is done in a typical ICA run), they're the same using the exact same
utilities and with md5sum.
$ gcc-build-1/gcc/build/genchecksum gcc-build-1/gcc/cc1-dummy
const unsigned char executable_checksum[16] = { 0x2a, 0xd3, 0x47,
0x76, 0xad, 0xf6, 0xbd, 0xa4, 0xe8, 0xae, 0x58, 00, 0x9, 0xa3, 0x4f,
0x80 };
$ gcc-build-2/gcc/build/genchecksum gcc-build-2/gcc/cc1-dummy
const unsigned char executable_checksum[16] = { 0x2a, 0xd3, 0x47,
0x76, 0xad, 0xf6, 0xbd, 0xa4, 0xe8, 0xae, 0x58, 00, 0x9, 0xa3, 0x4f,
0x80 };
$ md5sum gcc-build-1/gcc/cc1-dummy
56573eaa5575bfe0c98e2fa4219e51ff gcc-build-1/gcc/cc1-dummy
$ md5sum gcc-build-2/gcc/cc1-dummy
56573eaa5575bfe0c98e2fa4219e51ff gcc-build-2/gcc/cc1-dummy
So, it seems this difference is embedded in cc1 and can't be stripped
out after the build. I'm assuming that the original difference is just
debugging symbols like would normally be the case. I'll try to narrow
that down further, but this may be a false positive ICA regression.
It's interesting that DIY doesn't show the same issue. I'm going to
try to narrow down specifically what's different. Any ideas welcome.
I'm still a bit stumped that the two tweaks didn't fix the issue.
--
Dan
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
