RTLD_GLOBAL again (was Re: kdeutils/kregexpeditor/test)

[Martijn Klingens]

On Saturday 20 April 2002 21:37, Michael Matz wrote:
> there's basically no mean to ensure, that 3rd party libs don't produce
> symbol clashes with RTLD_GLOBAL, except postprocessing them with a program
> fiddling with symbol visibility (_and_ relocating the lib at the same
> time, in case it used some of it's own global symbols, which we want to
> get rid of), or at link time of that lib, which by definition isn't
> possible for us for 3rd party libs.  Also this is only possible on some
> binary formats, notably ELF.

Consider me stupid for replying on a topic that I hardly know anything about, 
but:

how difficult would it be for a plugin that loads e.g. libssl to be rewritten 
to do an explicit dlopen with RTLD_LOCAL for libssl, whereas the 
encapsulating plugin is properly loaded RTLD_GLOBAL ?

With my simple understanding that would solve almost the entire problem, 
because there are very little third party libs that are C++ and hence need 
dynamic_cast and it would open up the dynamic_cast again in the plugin 
itself.

Flame away :-)

Martijn