Removal of removing fixincludes.
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
>> 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.
> 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.
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