bugfindutils - Bugs: bug #19972, Failed compilation:...

 
 

bug #19972: Failed compilation: ABSOLUTE_STDINT_H expands to empty string

Submitter:  James Youngman <jay>
Submitted:  Sat 26 May 2007 12:46:01 PM UTC
   
 
Category:  find Severity:  3 - Normal
Item Group:  Compilation Failure Status:  Invalid
Privacy:  Public Assigned to:  jay
Originator Name:  Nelson H. F. Beebe Open/Closed:  Closed
Release:  4.3.6 Fixed Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Sun 03 Jun 2007 12:17:17 PM UTC, comment #1: 

This was due to a local copy stdint.h confusing things.

James Youngman <jay>
Group administrator
Sat 26 May 2007 12:46:01 PM UTC, original submission:  

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

I'm using gnulib as of 2007-04-17 (included in findutils 4.3.6)
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 emailed the above informationt to the gnulib mailing list in the hope that they will be able to help in diagnosis.


James Youngman <jay>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by jay (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 4 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2007-06-09 jay StatusFixed Invalid
        Open/ClosedOpen Closed
    2007-06-03 jay StatusIn Progress Fixed
    2007-05-27 jay SummaryFailed compilation: ABSOLUTE_STDINT_H nexpands to empty string Failed compilation: ABSOLUTE_STDINT_H expands to empty string

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code