This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [ANNOUNCEMENT] NEW: {libtirpc/libtirpc1/libtirpc-devel}-0.2.1-1


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]