Re: More questions on sysroots

[Brian Dessent <brian@dessent.net>]

NightStrike wrote:

> This is where it dies as follows:
> In file included from ../../../gcc/libgcc/../gcc/libgcc2.c:33:
> ../../../gcc/libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such
> file or directory
> ../../../gcc/libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No
> such file or directory
> ../../../gcc/libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such
> file or directory
> ../../../gcc/libgcc/../gcc/tsystem.h:103:20: error: string.h: No such
> file or directory
> ../../../gcc/libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such
> file or directory
> ../../../gcc/libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such
> file or directory

You cut out the part that would have been useful, namely the -B and -I
arguments passed to xgcc.

> I don't understand that error.  It says, for instance, that limits.h
> can't include limits.h.  How is that possible?  It also can't find any
> of the system headers that are in place.

The limits.h that was found is gcc's private copy, not the actual system
limits.h.  gcc uses this technique when it needs to amend the contents
of a system header, by installing its own limits.h in its private
include directory that contains the gcc-specific parts, and at the end
it does #include_next <limits.h> so that the actual system limits.h gets
picked up at that point.  It also does something similar when it needs
to deal with buggy/broken/noncompliant system headers, by making a copy
of the offending header in its private include dir and then fixincluding
it there, obviously without the include_next.  The details don't matter,
the error is materially equivalent to all of the above, namely, a system
header could not be found.

Brian