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
