This is the mail archive of the
mailing list for the glibc project.
Re: PATCH: BZ #14664: changing prefix breaks "make check-abi-libc"
- From: Roland McGrath <roland at hack dot frob dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 10 Dec 2012 11:31:03 -0800 (PST)
- Subject: Re: PATCH: BZ #14664: changing prefix breaks "make check-abi-libc"
- References: <20121210010033.GA8607@gmail.com>
I've only skimmed the two long threads on this subject. I can't tell
if they are resolving in the right directions or not. Here's what I
think about the subject (and, you know, I'm right about such things).
It was a mistake that _nl_default_dirname was made part of the public
ABI in the first place. But it was a long time ago, and we can't take
it out now. What we can do is make sure it doesn't get into new ABIs:
do not export it for configurations with a minimum version set of
GLIBC_2.17 or later.
I disagree entirely with the notion that configuration options such as
--prefix should affect the ABI. The fact that it does affect the ABI
is fallout of the mistake of including this symbol in the ABI at all.
It has always been the intent that the ABI be unaffected by such build
Given that the symbol is already part of the ABI, the exact size of
_nl_default_dirname is also part of the ABI and it cannot be
increased. check-abi should continue to check that the public ABI for
symbols in old version sets is exactly what it has been in the past.
However, given that what _nl_default_dirname is in the ABI is a const
array, I think it's entirely reasonable to say that actually using an
application definition of _nl_default_dirname instead of an internal
one is not part of the ABI. To wit, we in fact are not using
application definitions, by virtue of the libc_hidden_proto
declarations on the internal uses. So really this is a pro forma part
of the ABI and not a useful one at all.
To maintain pedantic ABI compatibility with any existing application
binaries that may be using _nl_default_dirname for their own purposes,
we must continue to export that in libc for runtime use, and it must
have its canonical value (the --prefix=/usr one).
So these are the things we should do:
1. To avoid confusion, use a new, different variable name for the
internal variable used in the implementations of bindtextdomain et
al. That variable will never be exported. Its value will be
LOCALEDIR, i.e. vary based on --prefix et al. All mentions of the
old name _nl_default_dirname in code actually doing anything should
be excised entirely.
2. To maintain ABI compatibility, define _nl_default_dirname under
#if SHLIB_COMPAT (GLIBC_2_0, GLIBC_2_17). This definition will be
for runtime only, so you cannot link new binaries against the symbol.
It will have its canonical value "/usr/share/locale", size 18 (0x12).
3. Audit the public ABI for symbols (especially data symbols) that
start with _. The default presumption is that no such symbol
should be in the public ABI. Given that they are already there,
this can be redressed only by making them runtime-only symbols and
removing them under #if SHLIB_COMPAT (GLIBC_2_0, GLIBC_2_17). For
cases that are actually kosher, we should document somewhere (wiki)
the exact set and the rationale for having symbols in the public
ABI that are in the private name space. Some classes are clearly
there for good reason, such as __*_chk, __errno_location,
__ctype_b_loc, etc. (where references come from use of public
interfaces via macros or inlines). Those stay as they are, but
need rationale recorded. Others had such good reasons in the past
but are now obsolete (__ctype_b); those become runtime-only, with
rationale recorded. Yet others were just mistakes, and those too
become runtime-only, with a record of the facts that they were
mistakes and that they persist in the runtime-only ABI only for
compatibility. New ABIs with new minimum version sets should be
checked to make sure we don't perpetuate past mistakes in contexts
where we can avoid them without breaking ABI compatibility.