This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Don't check ABI for _nl_default_dirname
On Mon, 10 Dec 2012, Andreas Jaeger wrote:
> Is _nl_default_dirname really used anywhere? I just did a grep on my
> system and did not get a single match besides libc itself,
>
> Still I fear there might be broken programs but why not change the ABI
> that this is not exported anymore for newly build applications and only
> for old one?
I think there are more symbols than just _nl_default_dirname that are
exported because of historial accidents, for which it would make sense to
export them only for old binaries (and so not at all for architectures
with a minimum symbol version postdating the change to export only for old
binaries). The other _nl_* symbols may be like that, and the unwinder
symbols exported at version GCC_3.0 on older architectures, for example.
Unless a symbol is declared in an installed glibc header (not just a
declaration conditional on _LIBC, but one for programs using glibc),
whether for direct use or use by a macro / inline function in that header,
having it available for linking by new binaries is suspect, though there
may be some exceptions where an implementation-namespace name is available
deliberately for use by libraries such as libgcc or libstdc++ without a
public declaration, or where a symbol was historically used without a
header declaration. Taking the lists of symbols in all libraries on an
old architecture such as 32-bit x86, and grepping the installed headers to
see what symbols are not mentioned, should provide an indicative list
(some of the symbols in which may already only be compatibility symbols).
This doesn't itself solve the _nl_default_dirname ABI problem - to do that
I support the approach of defining _nl_default_dirname to have the right
length always, not depending on the prefix, and using another variable
internally.
--
Joseph S. Myers
joseph@codesourcery.com