This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: BZ #14664: changing prefix breaks "make check-abi-libc"
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