On Thu, May 7, 2015 at 5:42 PM, Sviatoslav Chagaev
<sviatoslav.chag...@gmail.com> wrote:
...
> If we read the dynamic symbol tables of both libraries, here's what we
> see:
>
> $ readelf -sD libaa/libaa.so.1.0 libbb/libbb.so.1.0 | grep dup
> 31 34: 0000000000000bc0 3 FUNC GLOBAL DEFAULT 8
> duplicateFun
> 35 34: 0000000000000d10 6 FUNC GLOBAL DEFAULT 8
> duplicateFun
>
> Both symbols are of "function" type and "global" binding.
>
> Here's what SysV ABI [3] has to say regarding this about relocatable
> objects:
>
> When the link editor combines several relocatable object files,
> it does not allow multiple definitions of STB_GLOBAL symbols with the
> same name.
>
> But I think it makes sense to not allow this for shared objects too.
> How can one expect a program to work correctly if there is a
> collision between two shared objects which is silently ignored? This
> also seems like an illegitimate way to replace some functionality of
> another lib with your own...
This happens often enough to have a name: interposition, and must not
be considered a fatal error.
> Do you agree that when there are shared objects which have global-bound
> function symbols with the same name -- ld.so must not allow such a
> program to run/dlopen said shared objects?
I disagree. To quote the Solaris Linkers and Libraries Guide:
Another form of simple symbol resolution, interposition, occurs
between relocatable objects
and shared objects, or between multiple shared objects. In these
cases, when a symbol is
multiply-defined, the relocatable object, or the first definition
between multiple shared objects,
is silently taken by the link-editor. The relocatable object's
definition, or the first shared object's
definition, is said to interpose on all other definitions. This
interposition can be used to override
the functionality provided by another shared object.
Multiply-defined symbols that occur
between relocatable objects and shared objects, or between
multiple shared objects, are treated
identically. A symbols weak binding or global binding is
irrelevant. By resolving to the first
definition, regardless of the symbols binding, both the
link-editor and runtime linker behave
consistently.
That's not an extension; that's just the way the linker works.
Philip Guenther
