Re: Silly warnings from python-SunOS-5.8-sun4d-fafner

> > Again, it seems the standard headers contain an internal conflict.  is
> > there any way we could silence this, so we'll be able to see more
> > interesting warnings through the noise?

[...]
> ... it's a mess. Full files attached.

OK, I'll give up on this one for now, since it's only a warning.  But
maybeo someone else who's familiar with GCC and header files might
have a clue.

> > Also, the AIX-2-000000042E00-hal builds fail (and have been failing
> > for weeks) with an error in posixmodule.c:
> > 
> > ../python/dist/src/Modules/posixmodule.c: In function `posix_fdatasync':
> > ../python/dist/src/Modules/posixmodule.c:902: `fdatasync' undeclared (first use 
> > this function)
> > ../python/dist/src/Modules/posixmodule.c:902: (Each undeclared identifier is rep
> > orted only once
> > ../python/dist/src/Modules/posixmodule.c:902: for each function it appears in.)
> > 

[...]
> This is in /usr/include/unistd.h:
> 
>         extern int      fdatasync(int);
>         extern int      finfo(const char *, int, void *, int);
>         extern int      ffinfo(int, int, void *, int);
> 
>   #endif /* ndef _KERNEL */
> 
>   #endif /* _NO_PROTO */
> 
>   #define _AES_OS_VERSION 1               /* OSF, AES version */
> 
>   #endif /* _ALL_SOURCE */
> 
>   #endif /* _H_UNISTD */
> 
> Included to the end of file as it shows the defs required/not allowed.
> Full file attached.
> 
> Can I find out which unistd.h it looks in (there doesn't seem to be
> any other on the machine, but one never knows)?

This looks (also from looking at the full file) that either _NO_PROTO
is defined, or _ALL_SOURCE is not defined (I don't think _KERNEL would
be defined :-).  I doubt that _NO_PROTO is defined, because then we'd
get tons of warnings on account of -Wrequire-prototypes.  Could you
see if it doesn't define _ALL_SOURCE, and what the story behind that
is?

What I sometimes do is make an educated guess at whether a particular
line of code would be expanded, and then put an #error directive right
there, and recompile.  If the #error is triggered, my guess was right
(and I take it out again).  If it's *not* triggered, my guess was
wrong, and then I try to make an alternative hypothesis.

--Guido van Rossum (home page: http://www.python.org/~guido/)