[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-core-devel
Subject: Re: RTLD_GLOBAL again (was Re: kdeutils/kregexpeditor/test)
From: Martijn Klingens <klingens () kde ! org>
Date: 2002-04-20 21:42:04
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic