This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Do not use wildcard symbol names for public versions in Versions files
- From: Florian Weimer <fweimer at redhat dot com>
- To: Joseph Myers <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Thu, 20 Apr 2017 22:20:39 +0200
- Subject: Re: Do not use wildcard symbol names for public versions in Versions files
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx01.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com B292F8123D
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com B292F8123D
- References: <alpine.DEB.2.20.1704201958140.30917@digraph.polyomino.org.uk>
On 04/20/2017 09:58 PM, Joseph Myers wrote:
As noted in
<https://sourceware.org/ml/libc-alpha/2012-12/msg00240.html>,
stdlib/Versions and wcsmbs/Versions list some functions as
__strto*_internal and __wcsto*_internal rather than explicitly listing
the symbols to be exported (so any new internal function matching one
of those patterns would be wrongly added to version GLIBC_2.0), which
seems like a bad idea. This patch changes those files to list the
exported symbols explicitly. There are still entries in
sysdeps/nacl/Versions for __nacl_irt_*, but as GLIBC_PRIVATE symbols
that seems less significant.
Thanks for doing this. Looks good.
Tested with build-many-glibcs.py that installed stripped shared
libraries are unchanged by the patch.
Do you have a script for that?
Florian