Removal of removing fixincludes.

Greg Schafer gschafer at
Thu May 15 15:21:06 PDT 2003

On Wed, May 14, 2003 at 10:05:03AM -0500, Tushar Teredesai wrote:
> Greg Schafer wrote:
> >On Wed, May 14, 2003 at 09:12:03AM -0400, Zack Winkles wrote:
> > 
> >
> >>I don't really it see it that way. First be build binutils, which is
> >>against the host (doesn't matter for this discussion), then we build GCC
> >>with introduces our fixincludes stuff. We then build Glibc against that
> >>Glibc. RIGHT after that we rebuild GCC, this time disabling fixincludes,
> >>and that delets all of our fixedincludes. Now we have a nice clean
> >>   
> >>
> >It does? As the gcc-pass2 simply overwrites the gcc-pass1, I would have
> >thought the "fixed" headers will still be there in the same location and
> >thus still playing a role.
> > 
> >
> It cleans and then writes the directory.

Indeed it does. This will stop the polluted headers from getting into the
Ch 6 chroot. Yay!

But like the old method, the next non-glibc pkg (i.e. in this case,
gcc-pass2) is still prone to build failure. It doesn't fail currently on my
test builds, but the potential is definitley still there. Mark my words :-)

So we still have a fundamental problem that needs fixing.

> One possible solution: Install Gcc Pass 1 with fixincludes, and leave 
> the source around. Once the fixed headers are not required, apply the 
> fixincludes patch to the Makefile (the patch will need to be modified) 
> and run make install.

I haven't tested that. But my knowledge of the gcc build system and my gut
instincts tell me that it won't work.

Unsubscribe: send email to listar at
and put 'unsubscribe lfs-dev' in the subject header of the message

More information about the lfs-dev mailing list