This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- From: Alan Modra <amodra at gmail dot com>
- To: Andreas Schwab <schwab at suse dot de>
- Cc: Ulrich Weigand <uweigand at de dot ibm dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Fri, 15 Nov 2013 09:14:34 +1030
- Subject: Re: [PATCH] PowerPC64 ELFv2 ABI 6/6: Bump ld.so soname version number
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1311131535530 dot 24404 at digraph dot polyomino dot org dot uk> <201311131832 dot rADIWWl1006890 at d06av02 dot portsmouth dot uk dot ibm dot com> <20131114030709 dot GJ20756 at bubble dot grove dot modra dot org> <mvmbo1npe6q dot fsf at hawking dot suse dot de>
On Thu, Nov 14, 2013 at 09:42:21AM +0100, Andreas Schwab wrote:
> Alan Modra <amodra@gmail.com> writes:
>
> > We are very likely going to have a distro release off the 2.18 branch,
> > or at least based on source prior to the FSF 2.19 release. Correct me
> > if I'm wrong here, but I believe that distro glibc ought to be marked
> > as 2.18.
>
> That would have an incompatible ABI, so it won't happen.
I don't understand this reply. We intend to take the glibc 2.18 release
sources and apply a bunch of patches to add powerpc64le ELFv2 support.
This is going to happen. Whether you like it or not. We can't wait
for 2.19.
The resulting libc clearly isn't FSF glibc-2.18 but you can't be
saying that our libc is incompatible with FSF glibc-2.18 because
there is no powerpc64le FSF glibc to be incompatible with! I'm left
thinking you are issuing an edict from on high that the glibc 2.19
release will have this line in shlib-versions:
powerpc.*le-.*-linux.* DEFAULT GLIBC_2.19
In other words, the earliest symbol set supported by the official
powerpc64le glibc-2.19 will be GLIBC_2.19. That would indeed result
in an incompatible ABI, and make it impossible for anyone using our
libc to upgrade to the official glibc-2.19 when that comes out.
But the *only* reason for an incompatible ABI would be this single
line (and the corresponding line in nptl/shlib-versions)! What
technical reason do you have for not allowing that the earliest
symbol set might be set by something other than FSF glibc releases?
Or what am I missing here?
--
Alan Modra
Australia Development Lab, IBM