Expected semantics of versioned symbol resolution

[Florian Weimer <fweimer at redhat dot com>]

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.)

Thanks,
Florian