Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Waldo Bastian <bastian at kde dot org>]

On Tuesday 04 December 2001 02:50 pm, Joe Buck wrote:
> > The alternative, banning RTTI from KDE, isn't very attractive either.
>
> What if you only use RTLD_GLOBAL for those libraries that define base
> classes that you'll want to do RTTI with?  Or use it everywhere except
> with libraries that you know are problematic and sloppy with name spaces,
> like the flash plugin and OpenGL.

The problem that we had was with things like templates. If two plugins use the 
same template, they will get the same symbol-names. When the symbols are 
loaded in the global namespace, it can happen that plugin A resolves against 
the symbols of plugin B. When you now unload plugin B you will get a crash 
the next time you access plugin A.

(Unloading plugins is a risky business anyway, because with 2.9x the process 
will crash on exit when there were static objects declared within 
function-scope in the plugin.)

To what _extent_ does linking without RTLD_GLOBAL break RTTI? Looking at 
PR3993 breakage there seems to happen because the module that does the 
dlopen'ing doesn't strongly define class B (how do you call that, "class B 
isn't being emitted"?)  That situation could be prevented most of the time I 
think. (I believe such classes also have a negative impact on prelinking)

Wouldn't then the only remaining problem be classes that are defined in both 
plugin A and plugin B (e.g. template) but aren't defined in the module that 
loads them? RTTI-wise such classes would be considered distinct then if I 
understand correctly?

Franz: You described PR3993 as "another KDE2 blocking bug", where does this 
behaviour break stuff in KDE?

Cheers,
Waldo