This is the mail archive of the
mailing list for the glibc project.
Expected semantics of versioned symbol resolution
- From: Florian Weimer <fweimer at redhat dot com>
- To: GNU C Library <libc-alpha at sourceware dot org>
- Date: Mon, 9 May 2016 21:29:38 +0200
- Subject: Expected semantics of versioned symbol resolution
- Authentication-results: sourceware.org; auth=none
Do versioned symbols bind to a symbol name/version/soname combination,
or just a name/version combination?
The current ld.so behavior seems far from uniform. Existing binaries
reference pthread_mutex_lock, version GLIBC_2.2.5, soname libc.so.6.
Yet we clearly expect that these are bound to the pthread_mutex_lock in
libpthread.so.0, not the one in libc.so.6, once libpthread is loaded
(irrespective of the link order).
However, when I removed the fork symbol from libpthread.so.0, I had
failures which indicated that ld.so was *exclusively* looking at
libpthread.so.0 for the binding. It was not looking at the libc.so.6
DT_NEEDED dependency of libpthread.so.0 as a fallback.
Is this the expected behavior?
(I think I botched my earlier tests in my discussion about Andreas, when
we discussed options for replacing the broken IFUNC resolver for
fork/vfork in libpthread.so.0.)