Removal of removing fixincludes.
gschafer at zip.com.au
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 linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message
More information about the lfs-dev