Bug#232920: ld.so: unversioned symbols allowed to satisfy unresolved references to versioned symbols

[Daniel Jacobowitz <dan@debian.org>]

On Sun, Feb 15, 2004 at 01:55:46PM -0600, Steve Langasek wrote:
> Package: libc6
> Version: 2.3.2.ds1-11
> 
> It appears that, given:
> 
> library libbar, providing version BAR1 of symbol bar_sym1;
> library libquux, linked against libbar and using (version BAR1 of) bar_sym1;
> and program foo, linked with -rdynamic, providing unversioned symbol
>   bar_sym1, and dlopen()ing libquux,
> 
> the versioned reference to bar_sym1 from libquux will be resolved using
> the unversioned symbol in foo, instead of the versioned symbol in
> libbar.
> 
> This problem also manifests if the unversioned bar_sym1 symbol is
> provided by a library that was dlopen()ed prior to dlopen()ing libquux;
> if foo is linked against libquux rather than dlopen()ing it; and,
> presumably, if foo is linked against both a lib (libbar0) providing the
> unversioned symbol and against libquux, but libbar0 is opened first.
> 
> I had somehow reached the conclusion that this was documented and
> deliberate behavior, but Andrew Suffield <asuffield@debian.org>
> indicates otherwise and asked that I file a bug.  The attached tarball
> contains a small test case that can be used to reproduce the problem,
> showing that unversioned symbols are allowed to satisfy unresolved
> references to versioned symbols.

I am fairly positive that Andrew is wrong.  This behavior is, for
instance, one which allows LD_PRELOAD libraries to continue to work.
However, there is a definite shortage of conclusive documentation.  The
ELF gABI does not specify.  The Solaris documentation is distinctly
vague on this point.

Glibc says only:
              /* We can match the version information or use the
                 default one if it is not hidden.  */


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer