This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- From: Adam Conrad <adconrad at 0c3 dot net>
- To: munroesj at us dot ibm dot com
- Cc: Brooks Moses <brooks dot moses at dpdx dot net>, libc-alpha at sourceware dot org, carlos at redhat dot com
- Date: Fri, 31 Jan 2014 14:32:41 -0700
- Subject: Re: [PATCH] change GLIBC PPC64/ELF2 ABI default to 2.17
- Authentication-results: sourceware.org; auth=none
- References: <20140131201607 dot GG99202 at jinx> <1391202081 dot 1683 dot 17 dot camel at spokane1 dot rchland dot ibm dot com>
On Fri, Jan 31, 2014 at 03:01:21PM -0600, Steven Munroe wrote:
>
> Brooks it was established that there are at least 6 new symbols between
> GLIBC-2.17 and 2.18:
>
> http://www.sourceware.org/ml/libc-alpha/2014-01/msg00730.html
Yes, but so what? If you're providing glibc 2.17, you provide the symbols
that came with 2.17. The version tag on those symbols doesn't mean you're
providing glibc 2.18 (or 2.19), it just means you're pulling tricks to
provide @2.18 symbols on a 2.17 build.
There's no reason you need to backport the 2.18/2.19 symbols, unless you
are also providing libc-2.18.so in a libc_2.18 deb/rpm/whatever. If it's
a 2.17 library in a 2.17 package, there's no reason to provide newer-than
2.17 symbols, except for some paranoia that a user will, I'm not sure, read
the ELF table, note the 2.18-versioned symbols, assume that libc-2.17.so is
actually 2.18, and then complain that it's missing new 2.18 symbols?
Seems like, in a 2.17-based distro, where the goal is conformance across
archiectures, you'd not want to provide newer-than-2.17 symbols ever, and
the advertised symbol version is pretty much a moot point as an internal
implementation detail.
Obviously, the macros and such should also still advertise that the library
is 2.17 (because it is), or people would rightly expect to find symbols
that aren't there based on runtime and compile-time checks.
... Adam