From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19995 invoked by alias); 16 Jun 2014 18:55:00 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 19983 invoked by uid 89); 16 Jun 2014 18:55:00 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f48.google.com Received: from mail-qa0-f48.google.com (HELO mail-qa0-f48.google.com) (209.85.216.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 16 Jun 2014 18:54:59 +0000 Received: by mail-qa0-f48.google.com with SMTP id x12so7896742qac.7 for ; Mon, 16 Jun 2014 11:54:57 -0700 (PDT) X-Received: by 10.224.50.136 with SMTP id z8mr29300832qaf.66.1402944896949; Mon, 16 Jun 2014 11:54:56 -0700 (PDT) Received: from [192.168.0.100] (S0106000cf16f58b1.wp.shawcable.net. [24.79.212.134]) by mx.google.com with ESMTPSA id g17sm15961700qaq.44.2014.06.16.11.54.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 16 Jun 2014 11:54:56 -0700 (PDT) Message-ID: <539F3D84.5060005@cygwin.com> Date: Mon, 16 Jun 2014 18:55:00 -0000 From: Yaakov Selkowitz 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@cygwin.com Subject: Re: libtirpc and redeclared bindresvport/bindresvport_sa References: <5384368E.4000707@lysator.liu.se> In-Reply-To: <5384368E.4000707@lysator.liu.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-06/txt/msg00182.txt.bz2 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 ), 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