public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* libtirpc and redeclared bindresvport/bindresvport_sa
@ 2014-05-27 11:50 Peter Rosin
  2014-06-16 18:55 ` Yaakov Selkowitz
  0 siblings, 1 reply; 2+ messages in thread
From: Peter Rosin @ 2014-05-27 11:50 UTC (permalink / raw)
  To: cygwin

Hi!

I ran into this problem [1] when doing some RPC coding, and went
searching for a resolution. But I came up empty. Was there any
further discussion? Is this what is holding up the libvirt ITP?
I guess the window for releasing an ABI-incompatible libtirpc
0.2.1-2 is firmly closed.

Meanwhile, libtirpc-0.2.4 has been released, but this particular
problem probably remains [2].

Cheers,
Peter

[1] https://cygwin.com/ml/cygwin/2010-08/msg00659.html
[2] http://sourceforge.net/p/libtirpc/bugs/23/

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

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: libtirpc and redeclared bindresvport/bindresvport_sa
  2014-05-27 11:50 libtirpc and redeclared bindresvport/bindresvport_sa Peter Rosin
@ 2014-06-16 18:55 ` Yaakov Selkowitz
  0 siblings, 0 replies; 2+ messages in thread
From: Yaakov Selkowitz @ 2014-06-16 18:55 UTC (permalink / raw)
  To: cygwin

On 2014-05-27 01:54, Peter Rosin wrote:
> I ran into this problem [1] when doing some RPC coding, and went
> searching for a resolution. But I came up empty. Was there any
> further discussion?

AFAICS that thread is the extent of it.

> Is this what is holding up the libvirt ITP?

No, I think that would just be Eric's schedule.

> Meanwhile, libtirpc-0.2.4 has been released, but this particular
> problem probably remains [2].

The issue is an upstream one, and as you note, exists even on glibc 
platforms.  The function originates in sunrpc code, which is now 
maintained as libtirpc, but because it was treated as a generic 
networking function in glibc (declared in <netinet/in.h>), it is still 
provided even if the now-obsolete RPC code is not (IOW if glibc is 
configured w/o --enable-obsolete-rpc).

Since these are just redundant declarations and not conflicting ones, 
each existing for good reason, and the identical situation exists on 
glibc platforms, I don't think this is really an issue that needs to be 
addressed at this time.  If a real-world failure does occur, we can 
reassess the situation then.


Yaakov


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

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2014-06-16 18:55 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-05-27 11:50 libtirpc and redeclared bindresvport/bindresvport_sa Peter Rosin
2014-06-16 18:55 ` Yaakov Selkowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).