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 Aug 25 23:36, Charles Wilson wrote:
> On 8/21/2010 4:54 AM, Corinna Vinschen wrote:
> > 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.

Any idea, why?  I assume it really needs bindresvport_sa to support
the bindresvport functionality for IPv6, which is not supported by
glibc.  But it is supported on Cygwin, BSD, and others.

So, is that a configurable option?  In other words, does libtirpc
configury check for these functions on the target system?

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

Not much of a problem, I guess.  Given that the application is linked
against cygtirpc-1.dll anyway, it doesn't matter if it uses the libtirpc
or the cygwin implementation, same as on Linux.  At least not as long as
the cygtirpc-1.dll functions work correct.

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

Given the above, I think that the libtirpc headers just shouldn't
declare these functions on systems providing them via netdb.h.

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

Cygwin implements both APIs of getting the peer credentials, so the
libtirpc implementation of getpeereid is redundant, but should work.


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


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