Re: PATCH: BZ #14664: changing prefix breaks "make check-abi-libc"

[Roland McGrath <roland at hack dot frob dot 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
differences.

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.


Thanks,
Roland