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

[Guido van Rossum]

This version of Solaris (python-SunOS-5.8-sun4d-fafner) seems to have
a problem, or perhaps it's GCC. We get endless warnings (once per
file compiled!):

In file included from ../python/dist/src/Include/stringobject.h:10,
from ../python/dist/src/Include/Python.h:94,
from ../python/dist/src/Modules/python.c:3:
/sw/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include/stdarg.h:170: warning: redefinition of `va_list'
/usr/include/stdio.h:120: warning: `va_list' previously declared here

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?

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.)

Any suggestion for how to fix this? I'm guessing fdatasync() exists
in the library (else configure wouldn't have defined HAVE_FDATASYNC),
but it's not in the header files. Can someone verify that it's really
not in any header file? Then we should extend the section

#ifdef __hpux
extern int fdatasync(int); /* On HP-UX, in libc but not in unistd.h */
#endif

with a similar test for __sun.

Or, if it's in some header file but there's a magical symbol needed to
enable it, what's the symbol, and how can we get it defined?

Or perhaps configure should only #define HAVE_FDATASYNC if there's a
declaration for it?

Or perhaps we should rewrite the code to inline posix_fildes(), and
turn the problem into a warning?

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

[Anders Qvist]

At the moment, I'm a bit short on time, but here is some stuff to help
with the problem.

Post by Guido van Rossum
This version of Solaris (python-SunOS-5.8-sun4d-fafner) seems to have
a problem, or perhaps it's GCC. We get endless warnings (once per
In file included from ../python/dist/src/Include/stringobject.h:10,
from ../python/dist/src/Include/Python.h:94,
/sw/local/lib/gcc-lib/sparc-sun-solaris2.8/2.95.3/include/stdarg.h:170: warning: redefinition of `va_list'
/usr/include/stdio.h:120: warning: `va_list' previously declared here
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?

/*
* XPG4 requires that va_list be defined in <stdio.h> "as described in
* <stdarg.h>". ANSI-C and POSIX require that the namespace of <stdio.h>
* not be polluted with this name.
*/
#if defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4) && !defined(_VA_LIST)
#define _VA_LIST
typedef __va_list va_list;
#endif /* defined(_XOPEN_SOURCE) && (_XOPEN_VERSION - 0 >= 4) && ... */

... and further down:

#ifdef _STDARG_H
/* Define va_list, if desired, from __gnuc_va_list. */
/* We deliberately do not define va_list when called from
stdio.h, because ANSI C says that stdio.h is not supposed to define
va_list. stdio.h needs to have access to that data type,
but must not use that name. It should use the name __gnuc_va_list,
which is safe because it is reserved for the implementation. */

#ifdef _HIDDEN_VA_LIST /* On OSF1, this means varargs.h is "half-loaded". */
#undef _VA_LIST
#endif

#ifdef _BSD_VA_LIST
#undef _BSD_VA_LIST
#endif

#if defined(__svr4__) || (defined(_SCO_DS) && !defined(__VA_LIST))
/* SVR4.2 uses _VA_LIST for an internal alias for va_list,
so we must avoid testing it and setting it here.
SVR4 uses _VA_LIST as a flag in stdarg.h, but we should
have no conflict with that. */
#ifndef _VA_LIST_
#define _VA_LIST_
#ifdef __i860__
#ifndef _VA_LIST
#define _VA_LIST va_list
#endif
#endif /* __i860__ */
typedef __gnuc_va_list va_list;
#ifdef _SCO_DS
#define __VA_LIST
#endif
#endif /* _VA_LIST_ */
#else /* not __svr4__ || _SCO_DS */

/* The macro _VA_LIST_ is the same thing used by this file in Ultrix.
But on BSD NET2 we must not test or define or undef it.
(Note that the comments in NET 2's ansi.h
are incorrect for _VA_LIST_--see stdio.h!) */
#if !defined (_VA_LIST_) || defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__) || defined(WINNT)
/* The macro _VA_LIST_DEFINED is used in Windows NT 3.5 */
#ifndef _VA_LIST_DEFINED
/* The macro _VA_LIST is used in SCO Unix 3.2. */
#ifndef _VA_LIST
/* The macro _VA_LIST_T_H is used in the Bull dpx2 */
#ifndef _VA_LIST_T_H
typedef __gnuc_va_list va_list;
#endif /* not _VA_LIST_T_H */
#endif /* not _VA_LIST */
#endif /* not _VA_LIST_DEFINED */
#if !(defined (__BSD_NET2__) || defined (____386BSD____) || defined (__bsdi__) || defined (__sequent__) || defined (__FreeBSD__))
#define _VA_LIST_
#endif
#ifndef _VA_LIST
#define _VA_LIST
#endif
#ifndef _VA_LIST_DEFINED
#define _VA_LIST_DEFINED
#endif
#ifndef _VA_LIST_T_H
#define _VA_LIST_T_H
#endif

#endif /* not _VA_LIST_, except on certain systems */

#endif /* not __svr4__ */

#endif /* _STDARG_H */

... it's a mess. Full files attached.

Post by Guido van Rossum
Also, the AIX-2-000000042E00-hal builds fail (and have been failing
../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.)
Any suggestion for how to fix this? I'm guessing fdatasync() exists
in the library (else configure wouldn't have defined HAVE_FDATASYNC),
but it's not in the header files. Can someone verify that it's really
not in any header file? Then we should extend the section
#ifdef __hpux
extern int fdatasync(int); /* On HP-UX, in libc but not in unistd.h */
#endif
with a similar test for __sun.
Or, if it's in some header file but there's a magical symbol needed to
enable it, what's the symbol, and how can we get it defined?
Or perhaps configure should only #define HAVE_FDATASYNC if there's a
declaration for it?
Or perhaps we should rewrite the code to inline posix_fildes(), and
turn the problem into a warning?

***@hal [/usr/include]$ nm /usr/lib/libc.a | grep fdata
.fdatasync T 619804
fdatasync D 188972 12

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)?

[Guido van Rossum]

Post by Anders Qvist

Post by Guido van Rossum
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?

[...]

Post by Anders Qvist
... 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.

Post by Anders Qvist

Post by Guido van Rossum
Also, the AIX-2-000000042E00-hal builds fail (and have been failing
../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.)

[...]

Post by Anders Qvist
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/)

[Anders Qvist]

On Fri, Jul 19, 2002 at 03:49:21PM -0400, Guido van Rossum wrote:
[snip]

Post by Guido van Rossum

Post by Anders Qvist

Post by Guido van Rossum
Also, the AIX-2-000000042E00-hal builds fail (and have been failing
../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.)

[...]

Post by Anders Qvist
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?

No such luck:

#error _ALL_SOURCE defined
#error _NO_PROTO not defined
#error _KERNEL not defined
#error _H_UNISTD defined

The file also has its atime updated by a make command, so it's likely
to be used.

#ifdef _AIX
extern int fdatasync(int);
#endif

... solves the problem, but isn't very beautiful.

[Michael Hudson]

Post by Anders Qvist
The file also has its atime updated by a make command, so it's likely
to be used.
#ifdef _AIX
extern int fdatasync(int);
#endif
... solves the problem, but isn't very beautiful.

Can you try this patch? (+ associated changes to configure &
pyconfig.h.in, which I can send you if they're hard for you to
generate).

Index: configure.in
===================================================================
RCS file: /cvsroot/python/python/dist/src/configure.in,v
retrieving revision 1.335
diff -c -r1.335 configure.in
*** configure.in 20 Jul 2002 08:51:52 -0000 1.335
--- configure.in 22 Jul 2002 10:41:32 -0000
***************
*** 1656,1661 ****
--- 1656,1662 ----
)
)

+ AC_CHECK_DECLS([fdatasync])

# On OSF/1 V5.1, getaddrinfo is available, but a define
# for [no]getaddrinfo in netdb.h.
Index: Modules/posixmodule.c
===================================================================
RCS file: /cvsroot/python/python/dist/src/Modules/posixmodule.c,v
retrieving revision 2.244
diff -c -r2.244 posixmodule.c
*** Modules/posixmodule.c 15 Jul 2002 16:10:55 -0000 2.244
--- Modules/posixmodule.c 22 Jul 2002 10:41:33 -0000
***************
*** 887,894 ****

#ifdef HAVE_FDATASYNC

! #ifdef __hpux
! extern int fdatasync(int); /* On HP-UX, in libc but not in unistd.h */
#endif

PyDoc_STRVAR(posix_fdatasync__doc__,
--- 887,894 ----

#ifdef HAVE_FDATASYNC

! #if !HAVE_DECL_FDATASYNC
! extern int fdatasync(int);
#endif

PyDoc_STRVAR(posix_fdatasync__doc__,

Is Martin here? I'd like him to look at this before I checked it in...

Cheers,
M.

[Guido van Rossum]

Post by Anders Qvist

Post by Guido van Rossum
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?

#error _ALL_SOURCE defined
#error _NO_PROTO not defined
#error _KERNEL not defined
#error _H_UNISTD defined
The file also has its atime updated by a make command, so it's likely
to be used.
#ifdef _AIX
extern int fdatasync(int);
#endif
... solves the problem, but isn't very beautiful.

Did this get resolved, or is it still an open mystery?

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

[Anders Qvist]

Post by Michael Hudson

Post by Anders Qvist
The file also has its atime updated by a make command, so it's likely
to be used.
#ifdef _AIX
extern int fdatasync(int);
#endif
... solves the problem, but isn't very beautiful.

Can you try this patch? (+ associated changes to configure &
pyconfig.h.in, which I can send you if they're hard for you to
generate).

Can't find a machine with autoconf/automake that mounts the disk, so a
"full" patch would be appreciated.

Here you go.

I'll have to take care of that, but that will take some time.

Probably a good idea in the long run. Is it a goal of the snake-farm to
be able to test patches out before commiting them to CVS?

I've been thinking of having a dir where one can put patches to apply
after cvs updates.

Our goal is to produce a python that works on as many platforms as is
possible. If there are patches that are likely to break the build on
some platforms, of course we'll do our best to try them out. We can
always start the build manually.

[snip]

Results of patch coming later.