Removal of removing fixincludes.
winkie at linuxfromscratch.org
Wed May 14 06:12:03 PDT 2003
On Wed, May 14, 2003 at 11:01:55PM +1000, Greg Schafer (gschafer at zip.com.au) wrote:
> 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).
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
Chater 5 with Glibc 2.3.2, GCC 3.3, and no fixed includes, no matter
what we have on the host. It seems clean to me, and it works.
I hope that made sense.
> Some scripting hackery can certainly achieve the goal, but that is not a real
> clean solution from a book POV.
I strongly agree.
> 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..
Heh, enjoy yourself. I'm leaving that sickly beast alone.
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