On Mon, 2012-05-07 at 20:00 -0400, Jeremy Huntwork wrote:
> On 5/7/12 7:04 PM, Matt Burgess wrote:
> > There's a comment in linux/a.out.h that it fixed
> > up /tools/include/a.out.h so that looks OK. syslimits.h just includes
> > limits.sh, so that looks fine too. limits.h has been fixed but there's
> > no indication of which limits.h was used as input to it. I can only
> > assume it was /tools/include/limits.h due to the a.out.h fix and the
> > fact that no other headers from my host's devel packages have ended up
> > being fixed up.
>
> Yep it goes like this:
>
> #include <limits.h> -> gcc internal limits.h -> system limits.h
>
> I'm pretty certain that we're safe to remove it here; two final checks
> could put this to bed:
>
> pre-pass2:
> echo 'main (){}' | $LFS_TGT-gcc -x c - -v | grep -i include
>
> post-pass2:
> echo 'main (){}' | cc -x c - -v | grep -i include
>
> And just confirm that both are only looking for paths in $LFS/tools or
> /tools - nothing on the host system.
>
> If so, then all that section about fixincludes can be dropped from pass 2.
Are we only talking about changing pass 2 here? We also have a sed in
the final build of GCC in chapter 6 with the following explanatory text:
"The fixincludes script is known to occasionally erroneously attempt to
"fix" the system headers installed so far. As the headers up to this
point are known to not require fixing, issue the following command to
prevent the fixincludes script from running:"
I'm a little nervous about that paragraph; are we absolutely certain
that the headers we've installed so far will never need fixing up?
Regards,
Matt.
--
http://linuxfromscratch.org/mailman/listinfo/lfs-dev
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
