DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:message-id:date:from:mime-version:to:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	 q=dns; s=default; b=UvfykEB6xYQuNpNGuETjJdTja45CgnMyggG+q3gidZE
	zs5j6jOl8YzZxcVXLRVMoQEwA+Gs0sS7NAAo3qypbLzcbzre4rJ2vNoPOwHG8nfe
	QGSbQf7hr1ZrQXljuQlwVaju6X/ygoG793Ig81zB9/ZVgU9kmhG5h1ue9+iPBI5A
	=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Message-ID: <539F3D84.5060005@cygwin.com>
Date: Mon, 16 Jun 2014 13:55:00 -0500
From: Yaakov Selkowitz <yselkowitz AT cygwin DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: libtirpc and redeclared bindresvport/bindresvport_sa
References: <5384368E DOT 4000707 AT lysator DOT liu DOT se>
In-Reply-To: <5384368E.4000707@lysator.liu.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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