Re: [PATCH] libkdeinit symbol pruning

Karl Vogel <karl.vogel-/[email protected]>
Newsgroups gmane.comp.kde.devel.optimize
Message-ID <[email protected]>
On 19 Jul 2004, you wrote in gmane.comp.kde.devel.optimize:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Monday 19 July 2004 02:05, David Faure wrote:
>> On Monday 19 July 2004 01:06, Karl Vogel wrote:
>> > It will break apps that link to the libkdeinit_*.so's or dlopen
>> > them and try to resolve symbols other than kdemain... but I guess
>> > if any app does that, then it's already broken by violating the kde
>> > abi, no?! 
>>
>> Thinking about it, I'm not sure anyone links to a kdeinit module.
>> What people do, which is unportable, is to link to a kparts part, but
>> that's unrelated.
> 
> What if an application defines a plugin API that plugins can call? (Or
> worse, if the application doesn't define an API and plugins just call
> stuff all over the place) I guess the right thing to do is to give
> applications the opportunity to specify their own export map if they
> need to export additional symbols.

Since this patch only alters the kdeinit case, it has no effect on plugins. 
or anything else for that matter.

For the plugin scenario, the correct way would be to specify what is 
considered public and what not (ie. like QT_EXPORT in QT). E.g. define an 
extra class that is exported to plugins and make the rest private to the 
app. The extra class then acts as the plugin interface.

Added bonus is the better code generation.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.