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

Charles Wilson cygwin@cwilson.fastmail.fm
Thu Aug 26 13:26:00 GMT 2010


On 8/26/2010 4:26 AM, Corinna Vinschen wrote:
> 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?

No, it doesn't.

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

Well, it's a problem if I want to remove or rename the duplicate
functions now provided by cygtirpc-1.dll.

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

But that's quite difficult to implement, in practice.  You can't do this:

#ifndef HAVE_BINDRESVPORT
<declare bindresvport>
#endif

in an installed header, because then you'd ALSO have to install and
#include your version of config.h, which is a big no-no. Not to mention
the namespace conflicts inherent in the autoconf-generated HAVE_* macros.

So, you have to make this header an AC_OUTPUT() file, and arrange to
somehow munge rpc/rpc.h.in to DTRT depending on the value of
HAVE_BINDRESVPORT...

It is *doable* -- but not simple.

>> The following are exported by both cygtirpc-1.dll and cygwin1.dll:
>> 	bindresvport
>> 	bindresvport_sa
>> 	getpeereid (*)
> 
> Cygwin implements both APIs of getting the peer credentials, so the
> libtirpc implementation of getpeereid is redundant, but should work.

Yes, but I don't really like "hiding" the official implementation for no
good reason.  OTOH, that's what libtirpc does on linux -- my original
justification for doing it this way.

I'm of two minds on this.  On the one hand:

Notwithstanding the <rpc/rpc.h> re-declaration problem, I'd rather
either (a) rename these functions -- which breaks ABI back-compat, or
(b) remove them entirely from the build, which does that too -- but also
forces libtirpc itself to use cygwin's implementation.  Assuming it
works, I'd rather go with (b).  And not bump the DLL version number,
since libtirpc is so young.  But breaking the ABI without bumping the
DLL number is bad form, and this is all a lot more work than just:

On the other hand,

Just do it the way it is done on linux, and simply fix the header
redeclaration "problem".  That's less work :-)


Regardless of how I deal with the "duplicate" symbols, fixing the
<rpc/rpc.h> re-declaration problem implies substantial changes to the
cygport and patches, so it'll take some time to get it
right...especially given other urgent demands on my time right now
(updated cygutils, run, run2; deadline approaching for official
libtool-2.2.next, ...)

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



More information about the Cygwin mailing list