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

[Simon Hausmann <hausmann at kde dot org>]

On Sun, Dec 09, 2001 at 11:40:43PM -0800, Waldo Bastian wrote:
> 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)

I think both 'modules', the dlopen'ing app as well as the shared
library do contain the actual RTTI info. However (see also comments
on PR4993) neither the app has been linked with --export-dynamic nor
is the shared library dlopen'ed with RTDL_GLOBAL, hence the weak rtti
symbols in the shared library aren't resolved to the existing onces
in the app -> with duplicated RTTI info for the same class the
pointer comparison fails.

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

The regular expression editor is one example (it is loaded
dynamically in khtml/kate/klipper, exactly like in 3993) , some of
the texteditor interfaces in kdelibs/interfaces another one. If we
don't want to use RTLD_GLOBAL I see too solutions from our side:

1) Use intermediate shared libraries. Like the regular expression
   editor component gets another shared library to which all apps
   using the component would have to link against. This doesn't
   scale very well for a big amount of components.

2) Don't use C++ RTTI to determine whether the given object inherits
   from the pure base class but use Qt RTTI instead (qt_cast) .
   Syntactically not as beautiful (we could hide it behind a d-cast
   like template though) it does quite the same job as when C++ rtti
   falls back on the string comparison approach. (which while being
   slower should still be fine for KDE as we usually don't do that
   casting in inner loops or other time critical places - I think
   functionality is here more important)

Simon