bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: lib/dirent.in.h fails on AIX


From: Albert Chin
Subject: Re: lib/dirent.in.h fails on AIX
Date: Thu, 20 Nov 2008 10:46:41 -0600
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Nov 09, 2008 at 03:15:22PM +0100, Bruno Haible wrote:
> Albert Chin wrote:
> > > The fix that I found is to use "xlc -E -C" instead of "xlc -E". It has the
> > > effect of turning the config.status lines
> > > 
> > >   S["NEXT_SIGNAL_H"]="\"///usr/include/sys/signal.h\""
> > >   S["NEXT_DIRENT_H"]="\"\""
> > > 
> > > into
> > > 
> > >   S["NEXT_SIGNAL_H"]="\"///usr/include/signal.h\""
> > >   S["NEXT_DIRENT_H"]="\"///usr/include/dirent.h\""
> > 
> > This doesn't always work. On AIX 6.1 with the IBM v10 compiler:
> >   $ echo '#include <math.h>' > conftest.c
> >   $ xlc -E -C conftest.c | grep math.h
> > #line 6 "/usr/vac/include/math.h"
> > #line 1 "/usr/include/math.h"
> > /* bos61B src/bos/usr/include/math.h 1.28.11.1
> > */
> > /* "@(#)30  1.28.11.1  src/bos/usr/include/math.h, libm, bos61B, b2008_06B1 
> > 2/4/08 03:09:39" */
> >  * COMPONENT_NAME: (LIBM) math header file
> > #line 92 "/usr/include/math.h"
> >  *      The ANSI standard requires that certain values be in math.h.
> >  *      ANSI required entries in math.h
> >  * prototype in math.h.
> > #line 1324 "/usr/include/math.h"
> > #line 1358 "/usr/vac/include/math.h"
> > 
> > This results in:
> >   S["NEXT_MATH_H"]="\"///usr/vac/include/math.h\""
> > 
> > But this is wrong. What we want is:
> >   S["NEXT_MATH_H"]="\"///usr/include/math.h\""
> 
> No. If the compiler's <math.h> is actually /usr/vac/include/math.h, we *do*
> want  S["NEXT_MATH_H"]="\"///usr/vac/include/math.h\""
> 
> > else HUGE_VAL isn't found when lib/strtod.c is compiled.
> 
> Can you investigate what's happening there? You are implying that
> /usr/include/math.h defines HUGE_VAL, whereas
> /usr/vac/include/math.h, which includes it, does not? And this is with
> "xlc -D_ALL_SOURCE"?

(AIX 6.1)
  $ cat conftest.c
  #include "///usr/vac/include/math.h"
  int a = HUGE_VAL;
  $ xlc -D_ALL_SOURCE -E conftest.c | tail
  #line 2 "conftest.c"
  int a = HUGE_VAL;

  $ cat conftest.c
  #include "///usr/include/math.h"
  int a = HUGE_VAL;
  $ xlc -D_ALL_SOURCE -E conftest.c | tail
  extern long long int __multi64( long long int, long long int );
  extern long long int __divi64( long long int, long long int );
  extern unsigned long long int __divu64( unsigned long long int,
                                          unsigned long long int );
  extern long long int __maxi64( long long int, long long int );
  extern long long int __mini64( long long int, long long int );
  extern long long int __f64toi64rz( double );
  extern unsigned long long int __f64tou64rz( double );
  #line 2 "conftest.c"
  int a = (*((double *)(_DBLINF)));


(AIX 5.3)
  $ cat conftest.c
  #include "///usr/vac/include/math.h"
  int a = HUGE_VAL;
  $ xlc -D_ALL_SOURCE -E conftest.c | tail
  #line 2 "conftest.c"
  int a = HUGE_VAL;

  $ cat conftest.c
  #include "///usr/include/math.h"
  int a = HUGE_VAL;
  $ xlc -D_ALL_SOURCE -E conftest.c | tail
  extern long long int __multi64( long long int, long long int );
  extern long long int __divi64( long long int, long long int );
  extern unsigned long long int __divu64( unsigned long long int, 
                                          unsigned long long int );
  extern long long int __maxi64( long long int, long long int );
  extern long long int __mini64( long long int, long long int );
  extern long long int __f64toi64rz( double );
  extern unsigned long long int __f64tou64rz( double );
  #line 2 "conftest.c"
  int a = (*((double *)(_DBLINF)));

/usr/vac/include/math.h includes /usr/include/math.h with:
  #include_next <math.h>

I have no idea why:
  #include <math.h>
behaves differently than:
  #include "///usr/vac/include/math.h"
You'd figure with the #include_next <math.h> in /usr/vac/include/math.h
the behavior would be the same. However, the #include_next <math.h> in
/usr/vac/include/math.h is turned into a no-op.

-- 
albert chin (address@hidden)




reply via email to

[Prev in Thread] Current Thread [Next in Thread]