ABSOLUTE_STDINT_H being expanded as an empty string (Sun cc 5.0, 5.8 on Solaris 7, 8)

[James Youngman]

It seems to me that ABSOLUTE_STDINT_H can be used without being
defined.   When this happens a compilation error can result.  This
code:

#if @HAVE_STDINT_H@
# if defined __sgi && ! defined __c99
  /* Bypass IRIX's <stdint.h> if in C89 mode, since it merely annoys users
     with "This header file is to be used only for c99 mode compilations"
     diagnostics.  */
#  define __STDINT_H__
# endif
 /* Other systems may have an incomplete or buggy <stdint.h>.
    Include it before <inttypes.h>, since any "#include <stdint.h>"
    in <inttypes.h> would reinclude us, skipping our contents because
    _GL_STDINT_H is defined.  */
# include @ABSOLUTE_STDINT_H@
#endif

provokes an error message because @ABSOLUTE_STDINT_H@ expands to nothing :-

source='xstrtoumax.c' object='xstrtoumax.o' libtool=no \
       DEPDIR=.deps depmode=none /bin/ksh ../../build-aux/depcomp \
       cc -DHAVE_CONFIG_H -I. -I../..  -I../../intl
-I/usr/local/include  -I/usr/local/include -c xstrtoumax.c
"./stdint.h", line 47: empty file name

The configure output seems to support this idea:


checking for stdint.h... yes
checking for stdint.h... (cached) yes
checking absolute name of <stdint.h>...
checking whether stdint.h conforms to C99... no
checking absolute name of <stdint.h>... (cached)
checking whether stdint.h conforms to C99... (cached) no
checking for stdint.h... (cached) yes


My guess is that the cause of the problem is that findutils is
checking for stdint.h like this in configure.in:-

AC_CHECK_HEADERS(unistd.h sys/types.h inttypes.h fcntl.h locale.h stdint.h)
AC_CHECK_HEADERS(sys/param.h mntent.h sys/mnttab.h sys/mntio.h sys/mkdev.h)

My understanding is that that check will set $ac_cv_header_stdint_h
but not set $gl_cv_absolute_stdint_h.  So based on the following code
I am concerned that something might be going wrong with
gl_ABSOLUTE_HEADER:-

 dnl AC_INCLUDES_DEFAULT defines $ac_cv_header_stdint_h.
 if test $ac_cv_header_stdint_h = yes; then
   gl_ABSOLUTE_HEADER([stdint.h])
   ABSOLUTE_STDINT_H=\"$gl_cv_absolute_stdint_h\"
   HAVE_STDINT_H=1
 else
   ABSOLUTE_STDINT_H=\"no/such/file/stdint.h\"
   HAVE_STDINT_H=0
 fi

I guess it's possible that the problem is caused by my calling
AC_CHECK_HEADERS(stdint.h) either at all or in the wrong place, but to
be honest while I have looked at the code for gl_ABSOLUTE_HEADER, I
can neither easily figure out whether the code

`(eval "$ac_cpp conftest.$ac_ext") 2>&AS_MESSAGE_LOG_FD |
sed -n 
'\#/]m4_quote(m4_defn([gl_HEADER_NAME]))[#{s#.*"\(.*/]m4_quote(m4_defn([gl_HEADER_NAME]))[\)".*#\1#;s#^/[^/]#//&#;p;q;}'`

is being invoked at all, not whether this is really the cause of the problem.

I'm pretty sure that gl_ABSOLUTE_HEADER does work in other cases,
because the configure output indicates that it works for other files:-

checking absolute name of <sys/time.h>... ///usr/include/sys/time.h
checking for struct timeval... yes
checking for unsigned long long int... yes
checking absolute name of <stdint.h>...
checking whether stdint.h conforms to C99... no
checking sys/inttypes.h usability... yes

So I'd appreciate a few hints here.   I'm using gnulib as of
2007-04-17 (included in
ftp://alpha.gnu.org/gnu/findutils/findutils-4.3.6.tar.gz) but I'm
unable to retest with a later version, as I have no access to the
affected systems.   The affected systems are :-

$ cat * | egrep "(Machinetype|Remote cc version)"
Sun Ultra Enterprise 450/400 (4 UltraSPARC-II CPUs, 400 MHz);  Solaris 7
cc: WorkShop Compilers 5.0 98/12/15 C 5.0

Sun Ultra Enterprise 5500 (4 CPUs, 400 MHz UltraSPARC-II); Solaris 8
cc: Sun C 5.8 Patch 121015-04 2007/01/10

Sun Ultra Enterprise 5500 (4 CPUs, 400 MHz UltraSPARC-II); Solaris 8
cc: Sun C 5.8 Patch 121015-04 2007/01/10

I have not posted the logs containing the configure output as they
contain potentially sensitive information (for example IP addresses
and YP domain names).  I'm sure that Nelson (see the CC: list) will be
happy to provide details and output files.    I don't have the
config.log files either, sorry.

James.