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

[Lubos Lunak]

On Saturday 20 April 2002 01:02, Waldo Bastian wrote:
> On Friday 19 April 2002 03:38 pm, Lubos Lunak wrote:
> >  I've now again read the whole 'KDE hackers, please read' thread on gcc@
> > and we listed 2 problems there: Name clashes and unloading. From the
> > replies it looks like the unloading is fixed already, so the only problem
> > remaining are the name clashes.
>
> The problem with the name clashes is that they are mostly beyond our
> control. Making sure not to have name-clashes is relative easy in KDE CVS. 
> It is much harder to prevent name-clashes between plugins independently
> developed by two different third parties. (A third and a fourth party >:-)
>
> It took us a month to realize that a name-clash was introduced in KDE CVS
> and was causing crashes. If ksirc would not have been in KDE cvs I am
> pretty sure we would have released KDE 3.1 with a "class Item" in the
> global namespace because we wouldn't have noticed anything wrong. Why do
> you think this would be different with 3rd party plugin/part developers?

 Because we could write a script that would check that a kdemodule_LTLIBRARIES 
plugins is namespace clean and abort compilation if it wouldn't be? Ok, 
nothing so drastic, at least because of compilation time, but as I said, I 
think it should be quite easy to check that a plugin is namespace clean and 
incorporate it in the build system (we could even have 'Micr^H^H^H^H 
KDE-certified' plugins >:) ). This would be also documented somewhere in the 
plugins writing docs, and people not bothering to comply will simply risk 
writting plugins that will crash - they will be asking for it after all.
 And using namespaces is not that hard, just putting almost everything in .h 
and .cpp files in 'namespace Foo { ... }' and it's done (oh, and in case uic 
still can't handle namespaces, fixing it too).
 Checking that all plugins are compliant isn't what I'm worried about the 
RTLD_GLOBAL way. I don't see any real big problem there. What worries me is 
3rd party libraries not primarily written for KDE, but used by some KDE 
plugin, as that would require asking the library maker to fix the library, 
and in case they don't do so for some reason, using some linker magic or some 
ugly hacks. There would be maybe certain amount of libs for which no solution 
would be possible, the question is how much is this 'certain amount' and how 
significant it would be.

 Also, when you're talking about control, we'd have this at least under 
certain control, while with the RTLD_LOCAL way we'd be on our own with the 
compiler (and how many people here are not scared after looking at gcc 
sources? >;)  ), and possibly with more hacks, after something else breaks 
with RTLD_LOCAL too. IMHO if we can, we should rather do what the compiler 
developers say.

 BTW, that script I'm talking about would be basically something like:

 for i in `ldd plugin`; do
     nm -D $i | c++filt | grep -v "^pluginprefix1" | grep -v "^libprefix1" \
         && echo "Sorry dude, you didn't qualify for the next round"
 done

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