On Aug 20 21:07, Charles Wilson wrote: > On 8/20/2010 8:35 PM, Eric Blake wrote: > > In file included from ././remote/qemu_protocol.h:9, > > from remote/qemu_protocol.c:7: > > /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of > > 'bindresvport' [-Wredundant-decls] > > /usr/include/netinet/in.h:21: warning: previous declaration of > > 'bindresvport' was here > > /usr/include/tirpc/rpc/rpc.h:95: warning: redundant redeclaration of > > 'bindresvport_sa' [-Wredundant-decls] > > /usr/include/netinet/in.h:22: warning: previous declaration of > > 'bindresvport_sa' was here > > Well, looking at linux, the declarations in netinet/in.h are guarded by > #if defined __USE_MISC || defined __USE_GNU > > These symbols are activated in (linux's) features.h by: > #if defined _BSD_SOURCE || defined _SVID_SOURCE > # define __USE_MISC 1 > #endif > > #ifdef _GNU_SOURCE > # define __USE_GNU 1 > #endif > > Given that the only *SOURCE flags supported by cygwin's headers are: > _BSD_SOURCE > _POSIX_SOURCE > _XOPEN_SOURCE > _GNU_SOURCE > (and, the newlib headers don't employ the __USE_* indirection), I think > the correct fix is to modify cygwin's netinet/in.h to add the following > guard around the declaration of bindresvport and bindresvport_sa: > > #if defined(_BSD_SOURCE) || defined(_GNU_SOURCE) > > If you concur, I'll post a patch to that effect to cygwin-patches (we > use our own header, not newlib's, for netinet/in.h).
This is not the right solution. First, we don't support _BSD_SOURCE and _GNU_SOURCE, yet, since, as you can see in the comment in /usr/include/features.h, the groundwork is entirely missing. The _POSIX_SOURCE is used in newlib in the first place and we can and do use it as well. _XOPEN_SOURCE is only barely available for a few months now, but it's not actually used anywhere. However bindresvport and bindresvport_sa are guarded, they are part of the official system header netinet/in.h, and they exist in Cygwin. On Linux, bindresvport and bindresvport6 are available by default, *unless* you define something like _POSIX_SOURCE. Since newlib/Cygwin is missing the groundwork for a full-fledged features.h, your above suggestion would result in declaring bindresvport/bindresvport_sa *only if* the user explicitely defines _BSD_SOURCE or _GNU_SOURCE on the command line. That's not feasible. The question is, why does libtirpc declare the functions at all? Does it come with its own implementation? Whether or not, I think the problem are the libtirpc headers in the first place. There's a similar case with krb5 headers, where gssrpc/rpc.h declares bindresvport as well, but that's fixed by the gssrpc/rename.h header, which is included automatically by gssrpc/rpc.h via gssrpc/types.h: #define bindresvport gssrpc_bindresvport However, given that on Linux the declarations are available by default, you will see the same warnings when using libtirpc's rpc/rpc.h header in conjunction with netinet/in.h. I just tested it on Fedora 13: $ gcc -c -I/usr/include/tirpc -Wredundant-decls x.c In file included from x.c:3: /usr/include/tirpc/rpc/rpc.h:84: warning: redundant redeclaration of ‘bindresvport’ /usr/include/netinet/in.h:440: note: previous declaration of ‘bindresvport’ was here But note that this only occurs with -Wredundant-decls, which is not one of the default warnings. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
