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

 
 

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

Submitted by:  James Youngman <jay>
Submitted on:  Sat 26 May 2007 12:46:01 PM UTC  
 
Category: findSeverity: 3 - Normal
Item Group: Compilation FailureStatus: Invalid
Privacy: PublicAssigned to: James Youngman <jay>
Originator Name: Nelson H. F. BeebeOpen/Closed: Closed
Release: 4.3.6Fixed Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

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>
Project AdministratorIn charge of this item.
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>
Project AdministratorIn charge of this item.

 

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

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 4 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 09 Jun 2007 06:36:59 PM UTCjayStatusFixed=>Invalid
      Open/ClosedOpen=>Closed
    Sun 03 Jun 2007 12:17:52 PM UTCjayStatusIn Progress=>Fixed
    Sun 27 May 2007 11:21:47 AM UTCjaySummaryFailed 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.1-cleanup1