Removal of removing fixincludes.

Tushar Teredesai tushar at linuxfromscratch.org
Thu May 15 18:12:06 PDT 2003


Greg Schafer wrote:

> 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! :-)

Cool :-) I thought I was going bonkers.

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

See below.

> 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.
> 
Oh! I thought that the includes were fixed during "make install" when 
copying to the private include directory in $prefix/lib.

In that case, Ryan's solution seems to be the most appropriate and one 
which would always work.

--Tushar.

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