Loading Konqueror sidebar plugins using KLibLoader::library()
l.lunak at suse.cz
Tue Sep 26 18:13:08 BST 2006
Dne úterý 26 září 2006 16:40 Krzysztof Lichota napsal(a):
> David Faure napisał(a):
> > On Sunday 24 September 2006 17:07, Krzysztof Lichota wrote:
> >> I have come across the following problem: my Konqueror sidebar plugin
> >> has to export some symbols from its library to be used in its plugins.
> > globalLibrary() has always been said to be "the right thing to do". So I
> > wouldn't object to it being used there, as long as you check that it
> > still all works - e.g. that the current plugins don't have symbol
> > conflicts with the rest of the code [or with each other?].
> Checking symbol conflicts for all plugins does not seem to be possible
> for stable branch, as there might be some external plugins (not in KDE
> tree) which rely on current behaviour.
> So I think I will stick to current 2-library approach and maybe we
> should change it for KDE 4, giving explicit contract for plugins that
> they must not have conflicting symbols?
Although using RTLD_GLOBAL is theoretically the right solution, I think we
should actually try to avoid using it, as symbols clashes are simply bound to
happen from time to time, cause ugly problems and no "plugins must not
without mistakes" is going to change that. The problems with RTLD_LOCAL and
duplicate RTTI info is that for some classes gcc doesn't have a way to decide
on where to put it, so it puts it everywhere. For most classes it however can
select one class element to which it will key this data (e.g. it puts it with
the first non-inline virtual method implementation). I've already talked to
gcc developers about adding a warning that would detect classes which don't
have any key method and then just fixing all those classes should fix the
SUSE LINUX, s.r.o. e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12 tel: +420 284 028 972
190 00 Prague 9 fax: +420 284 028 951
Czech Republic http//www.suse.cz
More information about the kde-core-devel