Removal of removing fixincludes.

Greg Schafer gschafer at
Wed May 14 06:01:55 PDT 2003

On Tue, May 13, 2003 at 09:21:02PM -0400, Zack Winkles wrote:
> 'Allo everyone,
> I'm just here to see what the general concensus is on removing all the
> fixincludes stuff, at least for GCC Pass 2 (Ch5). It seems to so *A LOT*
> of problems, without contaminating our final system.
> GCC 3.3 requires it in more ways than one for LFS, system headers do all
> sorts of nasty things like using va_start where it shouldn't (I don't
> understand what that is, but fixincludes fixes it), and primarily misuse
> of the __thread keyword.
> If there are no complaints, I'd love to include fixincludes in GCC Pass
> 2 when I send in my patch to add GCC 3.3 to the book. Everybody let me
> know what you think!

I see you meant gcc pass 1.

It's a catch 22. We need the fixincludes to fix the "__thread" keyword
affected headers (and possibly the va_start thing you mention) but we don't
want the rest.

I don't think we can simply re-introduce the fixincludes en-masse. The
fundamental problem will still be there i.e. "fixed" headers from the host
can potentially contaminate the final system and break the build of the Ch 6
gcc (which is the same symptom when using the old build method).

Some scripting hackery can certainly achieve the goal, but that is not a real
clean solution from a book POV.

We might need to re-think how best to hack the fixincludes process. Instead
of just stopping the fixincludes script from running like we do now, we
might need to actually get inside the damn thing. I've looked at it. But
it's deep voodoo in there and hard to figure out..

Will look into this some more..

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