This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus summary around changing GLIBC PPC64 LE ABI default to 2.17
- From: Brooks Moses <bmoses at google dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>
- Cc: Adam Conrad <adconrad at 0c3 dot net>, Andreas Jaeger <aj at suse dot com>, Steven Munroe <sjmunroe at us dot ibm dot com>, Adhemerval Zanella <azanella at linux dot vnet dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jeff Law <law at redhat dot com>, Roland McGrath <roland at hack dot frob dot com>, Andreas Schwab <schwab at suse dot de>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 31 Jan 2014 16:12:46 -0800
- Subject: Re: Consensus summary around changing GLIBC PPC64 LE ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <52EC34E1 dot 7040008 at redhat dot com> <52EC3861 dot 7010503 at redhat dot com>
[resending, plain-text only]
I think you've missed an important nuance in this description of the
alternatives:
On Fri, Jan 31, 2014 at 3:57 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>
> (b) Stay on 2.1[78] sources using GLIBC_2.1[89] default ABI and backport
> all 2.1[89] symbols to produce a 2.1[78]-based release whose ABI
> is identical to the GLIBC_2.1[89] ABI released upstream.
Call that (b1). There's also:
(b2) Stay on 2.1[78] sources using a GLIBC 2.1[89] default symbol
version, and do not backport additional symbols, thereby producing a
2.1[78]-based release whose ABI is a strict subset of the
GLIBC_2.1[89] ABI released upstream.
> - It is expected that neither SUSE nor Canonical want to try have a hybrid
> symbol release either. Thus setting the ABI baseline to GLIBC_2.19
> places them in the same position it places other 2.17-based distributions
> with GLIBC_2.18 as the default ABI.
This may be expected for b1, but neither SUSE nor Canonical actually
objected to b2 and Adam strongly argued for it being a reasonable
solution.
There was an additional objection to b2, explained by Roland, that
having a strict subset of the GLIBC_2.1[89] ABI would result in
confusion in the RPM system about library dependencies of packages,
and similar lack of ability to detect mismatches at runtime, with the
result that a program that depended on a new-in-2.19 symbol would fail
at PLT resolution at some arbitrary time rather than failing in
startup.
With that said, I think the remainder of the description seems accurate.
- Brooks