This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- From: Adam Conrad <adconrad at 0c3 dot net>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, libc-alpha at sourceware dot org
- Date: Thu, 14 Nov 2013 08:57:05 -0700
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- Authentication-results: sourceware.org; auth=none
- References: <201311131517 dot rADFHZvf003435 at d06av02 dot portsmouth dot uk dot ibm dot com> <Pine dot LNX dot 4 dot 64 dot 1311131535530 dot 24404 at digraph dot polyomino dot org dot uk>
On Wed, Nov 13, 2013 at 03:38:00PM +0000, Joseph S. Myers wrote:
> The version there is wrong - it should be GLIBC_2.19, not GLIBC_2.18,
> since the 2.18 release did not in fact support little-endian. But apart
> from that, just the configure checks.
There's intent to release likely more than one distribution based on
glibc 2.18 and backported powerpc64le patches from 2.19/trunk. If
we version @2.18 and upstream versions @2.19, we either force a nasty
ABI horizon we need to fix, or we need to carry a version patch for,
well, ever, and be gratuitously incompatible with upstream. Neither
of those is appealing.
The FSF branch should reflect reality of what's being deployed, in
cases like this, not be used as a hammer to force others to see the
upstream view of reality.
So, while it's true that there will never be an FSF 2.18 release that
supports this platform (unless someone allows us to backport to a
point release), it causes exactly zero problems to have the base symbol
version set "too low", and is incredibly annoying to have it set too
You could version them all @2.4 and it wouldn't make a difference if
the only glibc you can install is >> 2.19 anyway.
(Obviously, new symbols need to be versioned carefully, but the initial
"base set" for a new port is really not a fragile thing, unless you set
it too high compared to the reality of deployment in the wild)