Bruno Haible <[EMAIL PROTECTED]> writes: > 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's the basic idea, yes. I had been planning to do that for some time, and the Sun Studio problem (and Simon's problem) pushed me over the edge. > Can't the same error still occur with other compilers, that don't support > include_next? Not likely. This error occurs because the compiler has its own header that uses 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? allocsa.c includes allocsa.h, which includes <alloca.h> (resolving to /opt/sun12/sunstudio12/prod/include/cc/alloca.h), which includes <sys/types.h> (resolving to /usr/include/sys/types.h), which eventually does this: #ifdef __USE_XOPEN # define __need_clock_t #endif #define __need_time_t #define __need_timer_t #define __need_clockid_t #include <time.h> This <time.h> resolves to "./time.h", which does this: #if defined __need_time_t || defined __need_clock_t || defined __need_timespec # if (__GNUC__ || 60000000 <= __DECC_VER) # include_next <time.h> # else # include "///opt/sun12/sunstudio12/prod/include/cc/time.h" # endif #else ... #endif This includes ///opt/sun12/sunstudio12/prod/include/cc/time.h, which starts off this way: #include_next <time.h> which resolves to "./time.h" so we are in a loop. > How can I reproduce it? In which package did you get the error? coreutils? Yes, coreutils CVS. You can also reproduce the problem with coreutils 6.9 if you configure with "./configure CC=cc", where "cc" is Sun Studio 12 cc. The machine in question is running CentOS 4.5.
