Loading Konqueror sidebar plugins using KLibLoader::library()
krzysiek at lichota.net
Wed Sep 27 09:47:10 BST 2006
Lubos Lunak napisał(a):
>> 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.
So how about letting developer decide how his plugin should be loaded?
We could add special entry to .desktop file. For example
"X-KDE-PluginInfo-LoadType". It would default to "local" if not present,
but developer could specify it with "global", so that plugin is loaded
I could work on such patch for KDE 3.5.6.
> 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
My problem is not related to RTTI, so it wouldn't solve it. And I guess
it will take long time before gcc update propagates to all users/developers.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 254 bytes
Desc: OpenPGP digital signature
More information about the kde-core-devel