Removal of removing fixincludes.

Greg Schafer gschafer at zip.com.au
Thu May 15 16:23:46 PDT 2003


On Thu, May 15, 2003 at 05:55:09PM -0500, Tushar Teredesai wrote:
> 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.

With all due respect dude, you seem to be misunderstanding the purpose of
fixincludes.

Fixincludes allows bootstrapping a new gcc, which would otherwise be
impossible due to broken and/or conflicting headers ON THE HOST! The
packages on the host cannot be patched! The headers are already installed
there and they cannot be changed!

> 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).

Hrm, I seem to be beating my head against a brick wall here :-)

The only way to settle this one will be to try it out (which I'm reluctant
to waste time on coz I believe it will not work - but happy to be proven
wrong tho'). But even so, even if it does work, it's not an optimal
solution IMHO.

Lets be clear. The only way to prove this is to find a host where breakage
DOES happen. And it doesn't happen on all hosts. Back with LFS4.0 (or was it
for 4.1?) Knoppix and RH8 were such hosts but I don't know if that still
holds. So if you test your theory, you haven't proven anything unless you
can get it to fail without disabling fixincludes first.

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

Nifty use of /bin/true! Nice. But it still doesn't fix the fundamental
problem IMHO.

Greg
-- 
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 mailing list