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

[Lubos Lunak]

On Saturday 20 April 2002 23:42, Martijn Klingens wrote:
> On Saturday 20 April 2002 21:37, Michael Matz wrote:
[snip]
>
> 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 ?

 This would work only for functions (using dlsym()), and of course somebody 
would have to bother writting all the wrapping functions. There's no way how 
to do it for variables or classes. Which means the "wider" interface from the 
library would be used the more difficult it would be. But probably this would 
be sufficient, given that such problematic libraries would be hopefully very 
rare (I'm actually not sure if any of currently existing plugins uses a 
library we can't affect that has namespace problems ... anyone?).


> 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.

 The dynamic_cast is only problem when done across libs, when it's done only 
inside the lib, it works fine.

On Saturday 20 April 2002 23:39, Waldo Bastian wrote:
> On Saturday 20 April 2002 12:37 pm, Michael Matz wrote:
> > Still, the problem remains, that RTLD_LOCAL is not the ideal.  We could
> > start to make the probability of having that problem smaller.  Put all of
> > KDE into K* namespaces (alternatively to prefix _all_ non-nested classes
> > with "K").  Provide a mean in the .desktop files to mark
> > "trusted" plugins.  Those would be loaded _GLOBAL, while all other only
> > _LOCAL.
>
> What's the point of that? You still can't use a dynamic cast if it is
> possible that a plugin/part is loaded with RTLD_LOCAL.

 I think we should now try to find an existing example of a library that can't 
be RTLD_GLOBAL loaded and we can't do anything about that. Which means the 
library is not namespace clean, we can't make the library developer make it 
namespace clean, and the API used from the library cannot be handled just 
using dlsym(). So, anyone? I don't know any (which doesn't mean much though).


> > And we can "register" known namespaces for other people, maintaining
> > uniqueness, so also helping third parties.  Those which don't use this
> > simply are then in error, if really a clash happens.
>
> I think it is a good idea to promote the use of namespaces. If we start now
> then maybe by the time of KDE 4.0 we can decide whether we can start
> loading all libs with RTLD_GLOBAL. Till that time qt_cast is the way to go
> IMO.

 Here I originally wanted to say that KDE4.0 is too long and such, but now 
after thinking about, if the only difference will be RTLD_LOCAL<->RTLD_GLOBAL 
and qt_cast<->dynamic_cast, then fine. This in fact means that we will be 
slowly moving to state when we will be pretending that we actually use 
RTLD_GLOBAL, just we won't yet.

 As I already said, the changes needed are writing the checking tool and then 
moving all code in .cpp and .h into namespace blocks, and maybe designer/iuc 
fixing.

-- 
 Lubos Lunak
 llunak at suse.cz ; l.lunak at kde.org
 http://dforce.sh.cvut.cz/~seli