On 8/21/2010 4:54 AM, Corinna Vinschen wrote:
> On Aug 20 21:07, Charles Wilson wrote:
>> 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.
OK.
> 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.
I see.
> On Linux, bindresvport and bindresvport6 are available by default,
> *unless* you define something like _POSIX_SOURCE.
Right...as you pointed out below, you get the same warning on linux.
> 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.
Yes, you are correct. :-(
> The question is, why does libtirpc declare the functions at all? Does
> it come with its own implementation?
Yes, it does. And, that implementation is used by the upstream source
for linux, in preference to the glibc-provided version. I followed that
pattern in libtirpc, as well: the libtirpc version is used in preference
to cygwin's.
Not because I think there is a problem with cygwin's, but simply because
I followed the linux pattern.
Given that, I think something similar to the krb5 solution could be used
here, as well.
Unfortunately, the current cygtirpc-1.dll exports its version of
bindresvport and bindresvport_sa. That is a *problem* because anything
built against it will expect to use ITS version from now on.
Unless I rebuild with renamed versions, and bump the API number.
Or, don't bump the API number and break stuff. Since it is a new
package, and so far only Erick's private libvirt seems to use it, I'm
actually leaning that way.
Eric, any thoughts?
> Whether or not, I think the
> problem are the libtirpc headers in the first place.
OK.
> But note that this only occurs with -Wredundant-decls, which is not one
> of the default warnings.
right, but this problem did lead to the discovery of a real issue in
cygtirpc-1.dll...
I wonder if there are more issues lurking here:
The following are exported by both cygtirpc-1.dll and cygwin1.dll:
bindresvport
bindresvport_sa
getpeereid (*)
(*) implemented using
error = getsockopt(s, SOL_SOCKET, SO_PEERCRED, &uc, &uclen);
and then picking uc.uid and uc.gid (after error checking, etc).
Note that there are a number of functions declared by cygwin's <netdb.h>
header, but are provided by cygtirpc:
void endrpcent (void);
struct rpcent *getrpcent (void);
struct rpcent *getrpcbyname (const char *);
struct rpcent *getrpcbynumber (int);
void setrpcent (int);
Interestingly, many of these apparently HAD been declared in
tirpc/rpc/rpcent.h, but were commented out (using C++ comment markers, I
might add). But, at least that means there is no conflict with these
symbols.
--
Chuck
--
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
