[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: ABSOLUTE_STDINT_H being expanded as an empty string (Sun cc 5.0, 5.8
Re: ABSOLUTE_STDINT_H being expanded as an empty string (Sun cc 5.0, 5.8 on Solaris 7, 8)
Sun, 27 May 2007 00:47:53 +0200
James Youngman wrote:
> It seems to me that ABSOLUTE_STDINT_H can be used without being
I cannot see under which conditions this could be the case.
Also, I don't reproduce this problem when compiling findutils-4.3.6 on
Solaris 7 with Sun cc 5.0.
> 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@
> 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
This error message indicates that @ABSOLUTE_STDINT_H@ expands into "".
> 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>...
Indeed. This is the problem.
> 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)
There is no problem with that. The value ac_cv_header_stdint_h is only used,
not overridden or modified.
> I guess it's possible that the problem is caused by my calling
This is just a guess. Have you tried removing it? I bet it would not help.
> `(eval "$ac_cpp conftest.$ac_ext") 2>&AS_MESSAGE_LOG_FD |
> sed -n
This is the code producing the value. I guess the $ac_cpp command led
to an error, for some reason that the user needs to investigate. The
investigation can use the config.log file, since - as you see - the
error output of the $ac_cpp command is piped to the config.log.
It would also help to show the configure command together with all
relevant environment variables (CC, CPP, CPPFLAGS).