Removal of removing fixincludes.

Tushar Teredesai tushart at
Thu May 15 15:55:09 PDT 2003

Greg Schafer wrote:

>On Wed, May 14, 2003 at 10:05:03AM -0500, Tushar Teredesai wrote:
>>Greg Schafer wrote:
>>>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.
We disabled the fixincludes script because it fixed headers that did not 
need fixing and it creates problems when never versions of packages are 
installed. If the fixincludes script fixes some headers that *need* to 
be fixed, the correct way would be to patch the packages whose header 
files needed the fixes.

>>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.
It is not related to the gcc build system at all, after compiling the ch 
5 glibc, just cd back to the gcc-build directory, patch gcc/Makefile it 
so that fixincludes is not run and then run make install. It will 
overwrite the previous gcc-Pass1 files (it is not compiling anything, 
just reinstalling).

Instead of patching gcc/Makefile, one more alternative to patching the 
Makefile is to cd to gcc-build directory, rm the script and 
then link script to /bin/true. The Makefile will think it ran successfully. This will leave a bogus README, but since this 
is Ch 5, it is not that big a deal.

Tushar Teredesai
  E-mail:    tushartATabbnmDOTcom
  Extension: 5267

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