exporting symbols (was Re: The goodness of goodness)

[Simon Hausmann]

On Sat, May 19, 2001 at 08:55:48PM +0200, Bernd Gehrmann wrote:
> On Fri, 18 May 2001, Simon Hausmann wrote:
> > On Wed, May 16, 2001 at 02:16:59PM +0200, Bernd Gehrmann wrote:
> > > > I would tend to call a KDevelop java support class 'Java<rest of classname>'
> > > > even if I could give it the same name as an existing C++ support class via
> > > > namespaces. Is it a good idea for each plugin to declare its own namespace?  I
> > > 
> > > Hmm, I don't even know. In principle parts only need to export a
> > > single symbol, namely the init_foo which returns a factory. So
> > > there would be no problem. OTOH, it doesn't look like kde doesn't
> > > use ld's feature to restrict exporting symbol tables...
> > 
> > I think it's a good idea to use namespaces for plugins.
> > 
> > We used this ld feature for exporting init_* only 
> > ('-export-symbols-regex 'init_.*'"' was part of KDE_PLUGIN), but IIRC it turned
> > out that it only works for linux (which makes it something we can't rely on,
> > as then you just 'move' the crashes to other platforms without eliminating
> > their cause ;-)
> 
> Aha, good to know :-) Wouldn't it make sense - even it's only for
> linux - not to export internal classes in kdelibs? AFAIK this will
> be done in gtk 2.0, and I would expect the effect to be even
> greater for C++, since in C 'static' functions aren't exported anyway,
> in contrast to 'private' methods in C++.

Given the increasing amount of symbols in kdelibs I think that would be
a good idea. I dunno how feasible this is though nor what the 
-export-magic-blah option is :-)

CC'ing to core-devel, hoping that Michael Matz sees it ;-)

Bye,
 Simon


-
to unsubscribe from this list send an email to kdevelop-devel-request at kdevelop.org with the following body:
unsubscribe »your-email-address«