Removal of removing fixincludes.

Greg Schafer gschafer at zip.com.au
Thu May 15 18:00:14 PDT 2003


On Thu, May 15, 2003 at 06:40:34PM -0500, Tushar Teredesai wrote:
> Correct me if I am wrong, but here is how I understand it:
> 
>   1. binutils compiled against host headers.
>   2. gcc-pass1 compiled against host headers and the broken headers are
>      fixed by fixinc.sh.
>   3. glibc compiled.
>   4. toolchain adjusted to only use /stage1.
>   5. all 'fixed' headers removed since they patched the host headers
>      (either Ryan's grep method, or the method mentioned in my previous
>      mail).
>   6. gcc-pass2 compiled against new glibc (without fixincludes since
>      there should be nothing to fix, the only headers it refers to are
>      in /stage1/include). If the build fails here because of incorrect
>      syntax in some header in /stage1/include, then it indicates that
>      the stage1 glibc headers are incorrect in which case they should
>      be patched.

Yes! Spot on! :-)

No 5. is the key. The problem is how best to do it.

> :-) The way I understood the problem was that once glibc is compiled in 
> /stage1 and the toolchain is adjusted, we need to remove the headers 
> that were fixed by fixinc.sh (and copied to /stage1/lib/gcc...) i.e. 
> Step 5 in the above list. Please let me know if I we are talking about 
> different problems! :)

You understand correctly. I just don't think your solution would work coz my
understanding of the gcc build process is:

 - during the build, gcc's private include dir is born
 - gcc's own private headers are dumped there
 - the result of the fixincldes process i.e. the fixed headers are dumped
   there as well.

The include dir now exists and now contains everything it needs. Patching
the makefile after the build will not change the contents of the include dir
coz fixincludes has already been run. make install just installs the whole
include dir.

Thats my theory anyway. All this talk is utterly useless until somebody
tests it :-)

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