Re: problem with #include_next<stdint.h> in /usr/include/idn-int.h

[Paul Eggert]

Bruno Haible <address@hidden> 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.