This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: dlopen and C++ libraries (vtables)
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.