From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <libc-alpha-return-74689-listarch-libc-alpha=sources.redhat.com@sourceware.org>
Received: (qmail 15515 invoked by alias); 11 Nov 2016 19:49:36 -0000
Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <libc-alpha.sourceware.org>
List-Subscribe: <mailto:libc-alpha-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: libc-alpha-owner@sourceware.org
Received: (qmail 15331 invoked by uid 89); 11 Nov 2016 19:49:19 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RCVD_IN_SORBS_SPAM autolearn=ham version=3.3.2 spammy=Hx-languages-length:1245, getaddrinfo, our
X-HELO: mail-qk0-f180.google.com
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:subject:to:references:cc:from:organization
         :message-id:date:user-agent:mime-version:in-reply-to
         :content-transfer-encoding;
        bh=OfAFUt6vHW7jYRdhQDvHKP3J4Ov+3eBFKfPyKO4n9GI=;
        b=V80RCIkFOdGvsLt/7LL84gU3lmh1dlLJ8lf0oUW5p0emoE4GZRLYsy23OzAddUTgLo
         BdZbg5Ybait/GvJ8hUslbQp8QLwWRSuHhHxdWRwRkqeReYjH8GXrnLtZJ77jr5Yise5t
         +4esLkzxm4FPeX6XAc3heFe1UysC6A6gNuk/sgU7gJ3CXNVs+0S82eWg5GNGnjtSOgMn
         119cw0hEK+TCUdUNMEChyc1ieVtB/pyQtshjek9HgS4O2DfEUoQpwcQeio2lXaYS+KNn
         KGnXCHhlui9Ftjdt1o3p7CGW9rd8C8zfobED8Ni38xDv9tam9+vnq0HaOPtaG7jXrXo+
         tPUw==
X-Gm-Message-State: ABUngve8JxqCTlODhIM/m39OI7d+yjeINxbEWpiF+TAVWYPPhbRjikCVo2TTu73Bbwps20ta
X-Received: by 10.55.5.65 with SMTP id 62mr2852705qkf.308.1478893755968;
        Fri, 11 Nov 2016 11:49:15 -0800 (PST)
Subject: Re: What to do about libidn?
To: Joseph Myers <joseph@codesourcery.com>,
 Florian Weimer <fweimer@redhat.com>
References: <44cead16-9db0-a4c0-82cd-1f6178260ed7@redhat.com>
 <alpine.DEB.2.20.1611082325180.23898@digraph.polyomino.org.uk>
Cc: GNU C Library <libc-alpha@sourceware.org>
From: Carlos O'Donell <carlos@redhat.com>
Message-ID: <a5bfa77a-8bd8-4c63-9aa4-a67a01403cc7@redhat.com>
Date: Fri, 11 Nov 2016 19:49:00 -0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.20.1611082325180.23898@digraph.polyomino.org.uk>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit
X-SW-Source: 2016-11/txt/msg00442.txt.bz2

On 11/08/2016 06:30 PM, Joseph Myers wrote:
> On Tue, 8 Nov 2016, Florian Weimer wrote:
> 
>> This has several problems:
> 
> 8. Updating libidn would be problematic for license reasons (it's 
> non-FSF-assigned and upsteam is now LGPLv3).
> 
>> Should we remove our internal copy and try to dlopen libidn2?  Maybe falling
>> back to libidn if libdn2 is unavailable?  Bundle libidn2?  Write our own
>> implementation?
> 
> Given that glibc's libidn add-on is not itself a public ABI or API, 
> dlopening an external library would seem a reasonable way of implementing 
> that getaddrinfo functionality.
> 
> Suppose we remove libidn (with or without keeping the libidn functionality 
> through dlopen of another library).  Then we have no in-tree uses of the 
> add-ons mechanism.  Do we have any use for keeping that mechanism for 
> out-of-tree add-ons, or should it be removed?
 
Is libdfp still an add-on?

It looks like in 2009 they converted to a stand-alone library.

I reviewed IEEE 754-2008 and found that we do require some DFP support
to fully implement the standard, which means if we did adopt libdfp code
we would do so directly and not as an add-on, so there would be no add-on
requirement there.

-- 
Cheers,
Carlos.