Re: [PATCH] libkdeinit symbol pruning

On Monday 19 July 2004 13:04, Waldo Bastian wrote:
> 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? 
That API would have to be implemented in a _library_.
You can't implement it in a module, since linking to a module is unportable (breaks
on BSD I think, on Mac OS X for sure).

> (Or worse, 
> if the application doesn't define an API and plugins just call stuff all over
> the place) 
Yes, as I said this currently happens, but it shouldn't, since it breaks on some systems
(e.g. Mac OS X, cf. the big koffice patch that was posted on koffice-devel some time
ago to add shared libs whereever something was linking to a kparts).

> 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.
I don't see the point. Existing code doesn't do that, and when fixing code we should
rather let it NOT link to a dlopened module. [Anyway this doesn't apply to kdeinit modules].

-- 
David Faure, [email protected], sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).