This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Documenting the (dynamic) linking rules for symbol versioning
- From: Florian Weimer <fweimer at redhat dot com>
- To: "Michael Kerrisk (man-pages)" <mtk dot manpages at gmail dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Cc: linux-man <linux-man at vger dot kernel dot org>, Siddhesh Poyarekar <siddhesh at sourceware dot org>, Carlos O'Donell <carlos at redhat dot com>, Rich Felker <dalias at aerifal dot cx>, "H.J. Lu" <hjl dot tools at gmail dot com>
- Date: Thu, 20 Apr 2017 10:49:25 +0200
- Subject: Re: Documenting the (dynamic) linking rules for symbol versioning
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=fweimer at redhat dot com
- Dkim-filter: OpenDKIM Filter v2.11.0 mx1.redhat.com C2632C05683F
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com C2632C05683F
- References: <b3a962de-6703-d8b9-18f7-138185171475@gmail.com> <ee5e8057-7afa-c919-8ccb-9c8e6d0833c4@redhat.com> <517c3e75-93b5-0762-d6a4-7a17d196654e@gmail.com>
On 04/19/2017 09:49 PM, Michael Kerrisk (man-pages) wrote:
Hi Florian,
Thanks for your answers.
On 04/19/2017 05:48 PM, Florian Weimer wrote:
On 04/19/2017 05:07 PM, Michael Kerrisk (man-pages) wrote:
Am I right about my rough guess for the rationale for point 6,
or is there something else I should know/write about?
We currently have a bug where the symbol resolution depends on the order
of alternatives along a hash bucket list:
<https://sourceware.org/bugzilla/show_bug.cgi?id=12977#c2>
Okay.
What I was trying to say is that point 6 might be a bug.
But I think the problem there is that the file format only has one
global base version, not different per-symbol base versions. Your
second symbol with the unexpected binding simply does not have a base
version at all.
Another open problem is what happens when a versioned symbol moves from
one DSO to another. This is not a problem for unversioned symbols, but
we currently have a soname check for versioned symbols. This is rather
odd because this check isn't used to accelerate lookups. It does not
prevent symbol interposition from other DSOs, it merely introduces
spurious failures.
I have a vague recollection that this problem has been around for a
very long time, right?
Yes, it has.
7. The way to remove a versioned symbol from a new release
of a shared library is to not define a default version
(NAME@@VERSION) for that symbol. (Right?)
In other words, if we wanted to create a VER_4 of lib_ver.so
that removed the symbol 'abc', we simply don't create use
the usual asm(".symver") magic to create abc@VER_4.
You still need to use .symver, but with a @ version instead of a @@ version.
Why is that? What functionally is the difference between
having no .symver and a .symver with an @ version? (I tried
both, and they *both* result in undefined symbol errors from
ld(1), as I expected.
I was assuming that you want to preserve ABI. People who are interested
in symbol versioning usually want that. :)
Thanks,
Florian