ICA diff in cc1 and cc1plus

Dan Nicholson dbn.lists at gmail.com
Wed Mar 14 20:13:55 PDT 2007

On 3/14/07, Greg Schafer <gschafer at zip.com.au> 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.

Yeah, my thinking was always "fix the headers issue when it actually
breaks something". So, this is sort of a blessing :)

> > 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.

I agree. I was thinking about this later, and for something as core as
the C libraries, it makes sense to try to provide the same version in
the temptools as the final build as much as possible. Even if the Ch.
6 toolchain adjustment is changed to do the right thing, it doesn't
make sense to introduce a difference between the two stages if it can
be prevented.

> > More info as it arrives.
> Good detective work :-)

Thanks. It took a few days work of dusting off the ICA driver for my
scripts, but it was worth it. An impressive tool even when you have to
weed through some red herrings.

Strangely, my brand new Core2 Duo 6400 seems slower on builds then my
Core Duo laptop. Maybe it's because it's running on a big bloated
Rawhide right now.


More information about the lfs-dev mailing list