Re: Problem linking to wrong class

[Andrew Haley <aph at redhat dot com>]

Brian Peschel wrote:
> 
>>
>> You get no warning because ELF linkers support symbol interposition.
>>
>> In your case, the symbol defined by the static library becomes a symbol
>> defined in the main executable.  There is, by default, a single global
>> namespace of symbols defined in the main executable and in shared
>> libraries.  When the executable and a shared library both define the
>> same symbol, the one in the executable takes precedence.  All references
>> in the shared library to that symbol become references to the symbol
>> definition in the executable.  This is not an error.
>>
>> ELF works this way because it means that if the executable defines
>> "malloc", the shared libc will call the "malloc" defined in the
>> executable, rather than calling its own malloc.  This is considered to
>> be a feature.
>>
>> You can adjust this default behaviour in various way, primarily by using
>> symbol visibility.

> Is there an option on the linker to at least warn me it is doing this? 

It's not doing anything wrong.  If you have a bunch of libraries with
the global symbol foo, they all end up referring to the same symbol.
This is perfectly normal C/C++ behaviour, as the standards say: there
can only be a single copy of a variable called foo in a running program
unless that variable is declared static.  People writing shared libraries
need to be careful about namespace control.  These days this is pretty
easy, at least in C++ with namespaces.

> I understand why it is happening now (thanks!) at least.  But I am
> worried about this same problem elsewhere.  I expect this could happen
> to me with 3rd party libraries I use.  And unless a crash happens (like
> it did in this case with my own libraries), it would be difficult to
> diagnose.

Quite possibly, but this is so common that you'd get a ton of spurious
warnings.  For example, some threads libraries redefine many system
functions.

Andrew.