Loading Konqueror sidebar plugins using KLibLoader::library()

[Krzysztof Lichota]

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
using globalLibrary().

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 
> problem.

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.

	Krzysztof Lichota


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060927/6b41c0c2/attachment.sig>