This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libcidn
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Andreas K. Huettel" <dilfridge at gentoo dot org>
- Cc: libc-alpha at sourceware dot org
- Date: Thu, 5 Oct 2017 15:40:19 +0200
- Subject: Re: libcidn
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1E342780D8
- References: <alpine.DEB.2.20.1709281748010.30081@digraph.polyomino.org.uk> <d079cb89-4f6d-31a1-623e-277383d8fe3a@redhat.com> <alpine.DEB.2.20.1710051253180.18935@digraph.polyomino.org.uk> <1745056.Yiv6T0xlHe@porto>
On 10/05/2017 03:16 PM, Andreas K. Huettel wrote:
Mostly out of curiosity, what is the usecase for the glibc-internal libidn?
It's used by getaddrinfo if the AI_IDN flag is passed.
A quick scan on my laptop (Gentoo Linux) shows no binaries that have
libcidn.so in NEEDED (but many with the separate libidn.so).
It's not linked directly. getaddrinfo loads it on demand. It's this
way because no one has changed it yet (I tried, but got sidetracked by
dynamic linker issues). We should rewrite the code so that it tries
(external) libidn2 first, then (external) libidn, and then bails out,
and remove the actual IDN code from the library. Some care is necessary
because we should switch from dlsym to dlvsym for the lookup, for
forwards compatibility.
Thanks,
Florian