dlopen and C++ libraries (vtables)

[Carlos O'Donell]

On 7/20/2011 9:39 AM, Matthew Chapman wrote:
> However, if main loads libmine.so with dlopen(), things can go bad.
> During relocation processing, the dynamic linker decides:
>       3199:     file=./libmine.so [0];  needed by
> /usr/lib64/libxerces-c.so [0] (relocation dependency)
> (_ZTVN11xercesc_2_713XSerializableE)
> 
> i.e. there is a false circular dependency created where libxerces-c.so
> requires ./libmine.so.  The problem is that the same vtables and
> typeinfo structures will often be weakly defined in both libraries,
> e.g.:
> 
> ./libmine.so:
> 0000000000200df0 V _ZTVN11xercesc_2_813XSerializableE
> /usr/lib64/libxerces-c.so:
> 00000000005797a0 V _ZTVN11xercesc_2_813XSerializableE
> 
> and it seems that the first one is always chosen (load order rather
> than dependency order?).

Why do you call this a false circular dependency?

You can have two DSO, each with a weak symbol, and the dynamic linker
gets to choose whichever one it wants.

Even speaking about C++ this is still valid, you can emit multiple
vtables, see the rules for "vague linkage" in the compiler documentation.
 
> The problem then is that - due to the false dependency - the libraries
> then sometimes get unloaded in the wrong order, causing symbol
> resolution errors (or worse) in destructors.  I can come up with a
> test case if needed.

You need to prove they are unloaded in the wrong order.

> As previously noted this doesn't happen when the library is loaded as
> part of the normal dependencies, which must use a different resolution
> order.
> 
> Are there any ways of getting around this behaviour?  I've tried
> various dlopen flags with no success so far.  I would argue that it if
> it's possible to make libmine.so load correctly at startup, it should
> also be possible to make it work with dlopen()...

You need to provide a reduced test case that shows the behaviour.

Cheers,
CArlos.