Hi Paul, Thanks for your patch. But how does it solve the original problem? Only because it enables include_next for compilers that support it, and Sun Studio cc happens to be one of these compilers, right?
> That compiler supports #include_next but is not GCC. > It gets into recursive inclusion loops, for example: > > cc -I. -g -c allocsa.c > "///opt/sun12/sunstudio12/prod/include/cc/time.h", line 6: too many open > files: <time.h> > "./time.h", line 28: too many open files: > "///opt/sun12/sunstudio12/prod/include/cc/time.h" > "///opt/sun12/sunstudio12/prod/include/cc/stdlib.h", line 6: too many open > files: <stdlib.h> > "./unistd.h", line 26: too many open files: > "///opt/sun12/sunstudio12/prod/include/cc/unistd.h" > "./unistd.h", line 35: too many open files: <stdio.h> > "./unistd.h", line 39: too many open files: <stdlib.h> > "./unistd.h", line 136: too many open files: <stdlib.h> > "allocsa.c", line 74: warning: implicit function declaration: malloc > "allocsa.c", line 128: warning: implicit function declaration: free > cc: acomp failed for allocsa.c Can't the same error still occur with other compilers, that don't support include_next? Where does the error actually come from? Has the absolute pathname of a gnulib header been substituted into itself? Or is there a #include loop that we weren't aware of? How can I reproduce it? In which package did you get the error? coreutils? Bruno
