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

[Rich Felker <dalias at aerifal dot cx>]

On Mon, Dec 10, 2012 at 11:31:03AM -0800, Roland McGrath wrote:
> 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.

Isn't it also possible to prevent newly-linked applications from
linking to it, so that only existing binaries are able to use it?
This is analogous to the recent __secure_getenv discussion where
applications were wrongly using the internal __secure_getenv symbol,
and I believe the resolution was to prevent any further linking to it
and replace it with secure_getenv.

> 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.

I agree completely. To be more concrete, there's no justifiable reason
an application linked to glibc on a "normal" system should fail to
work on a system where glibc is installed as a non-default libc under
some prefix like /usr/glibc-compat or similar.

> 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.

Agreed.

> 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.

Agree completely with all three points.

Rich