Re: What to do about libidn?

[Carlos O'Donell <carlos@redhat.com>]

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.