On Thursday 18 April 2002 20:25, Waldo Bastian wrote:
> On Thursday 18 April 2002 09:10 am, Malte Starostik wrote:
> > > http://lists.kde.org/?l=kde-devel&m=101225826622056&w=2
> > >
> > >  Can't we put this in some FAQ?
> >
> > IMHO this is really very evil.
> > Wouldn't it be cleaner - and producing less surprises - to always load
> > plugins with RTLD_GLOBAL and have a policy that every KDE plugin MUST (as
> > in RFCs :) put symbols it defines into an own namespace?
>
> No, since there is no way that we could enforce such policy it i unlikely
> to be followed and will result in crashes that are much harder to track
> down.

 Thinking about it, wouldn't it be still better, at least in the long run, to 
use RTLD_GLOBAL. Gcc folks made it clear that they aren't going to do 
anything about that and that they simply assume that every symbols exists 
only once in the process. Which means we a) will stick with qt_cast forever, 
b) go for RTLD_GLOBAL sooner or later , c) is there any c) ?
 
 In favour of b) speaks also the fact there may be other problem with multiple 
instances of the same symbol, e.g. if we finally start using exceptions 
seriously one day, the underlying implementation may break too (I'm not sure 
here, we'd have to ask). Going against the compiler developers might get us 
on even more dangerous ground, and finding/solving such problem could be even 
worse than finding clashing symbols and getting slowly to make everything 
namespace clean.

 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.

 If we now start putting things in their own namespaces, this could probably 
avoid name clashes sufficiently. Our own code would be without problems, 
everything would be in namespaces. Using namespaces is not that hard (the 
only place where it sucks is gdb, and uic would need some fixing in this 
area).

 So the only remaining problem would be plugins using 3rd party libraries 
(IIRC we already had such problem with ... was it libfam and libGL?). This 
one would be a bit difficult, and I don't know enough about this area. The 
problem here is that once you dlopen() something globally, it will make 
global also all its dependencies, so either the plugins shouldn't link 
against the problematic library, or there would be some linker voodoo magic 
needed to hide them (oh, and one could try to also ask whoever made the 
library to fix it). Not linking against the library would be quite simple if 
only few symbols would be needed, just a local dlopen() and few dlsym() calls 
would do. I have no idea about filtering symbols from the library or hiding 
them, in ld documentation I noticed options --filter and --wrap, but neither 
of them seems to really help. Hmm, in fact dlsym() could probably work fine 
even for larger libs, if the wrapper library would be script generated, in 
case there no way to do this in the linker.

 Could somebody with enough linker knowledge comment on this? Or we could ask 
gcc developers >;), if they say we can't do it the RTLD_LOCAL way, they will 
surely known how to make it work the RTLD_GLOBAL way ... or maybe they won't.

>
> The recent ksirc crashes are an example of exactly such crashes.

 Checking the all plugins for clashes shouldn't be that hard - 'ldd', 'nm -D', 
'c++filt' and a script should be able to easily check that a plugin exports 
only allowed symbols.

 Also, IIRC there were people who used gcc3.0.x with KDE and made the 
dynamic_cast problems go away by changing KDE to always use RTLD_GLOBAL. Name 
clashes between libs should be quite rare and easy to check (don't bother 
with 'famous last words', I've had already enough of that). If the clashes 
can be easily checked, they can be easily avoided, and non-conforming plugins 
will simply in certain combinations crash, so what?

 Comments, flames, questions, descriptions of linker behaviour?

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