version script for libkdeui

[Lubos Lunak]

On Sunday 14 of March 2004 03:36, Luciano Montanaro wrote:
> On Saturday 13 March 2004 21:06, Lubos Lunak wrote:
> > Dne so 13. března 2004 17:23 Luciano Montanaro napsal(a):
> > > I have spent some time trying to build a version script for the kdeui
> > > library, like those currently available for libkjs and libkhtml.
> > > It contains all the classes which are in the NOINST includes,
> > > plus a few that seem to be marked as private.
> > >
> > > I am trying the library just now, and it does not seem to have any
> > > bad effect. Using the script, 313 "T" symbols are hidden in the
> > > library, out out of 5435. That's not much. I'd like to try the same for
> > > libkio and libkdecore. Do you think the effort is worth it?
> >
> >  No. You'd have to update the files until the end of your life ;).
>
> If the version scripts had to be perfectly accurate, yes. Is that really
> needed? The approach is similar to that used for the khtml and kjs modules,
> and yes, I agree it is more of a stopgap measure than anything else.

 Damn. I'll have to write the script for --enable-nmcheck myself then ;).

>
> >  I suggest writing a script that will read all to-be-installed *.h files,
> > check for KDE_EXPORT/KDE_NO_EXPORT, and build the file from that.
>
> If the includes already used the KDE_EXPORT/KDE_NO_EXPORT macros, there
> would be no need for version scripts (or very little). The KDE_NO_EXPORT
> macro expands to __attribute__((visibility("hidden"))), while KDE_EXPORT
> expands to __attribute__((visibility("visible"))) (which, by the way, is
> not documented in the Gcc documentation. Is it ever used? I suspect not...)
> so the effect should be the same as putting the symbol in the local list.
> The symbols that can't be hidden this way are the vtable and typeinfo
> symbols for the various classes, which, if I remember correctly, are quite
> interesting things to hide. Am I missing something else?

 That's actually exactly my point. Gcc currently can't hide a whole class. The 
linker can. And this we'll stay to be the case until everybody upgrades to 
gcc-3.4(hopefully it'll be fixed there). So by using the macros the sources 
will be prepared for such compilers, and it'll be clear what's public and 
what's not, while a script converting this info to a linker script would 
provide (and keep up to date) this information for people without such 
compiler.

 It's probably enough to have just such a brief list of symbols to exclude 
from exporting for performance reasons though. I thought this could save me 
some work with --enable-nmcheck for KDE4. In order to have rtti/exceptions 
working across DSO boundaries, we need to use RTLD_GLOBAL, and for that, 
binaries need to be namespace clean. I have somewhere in my KDE4 TODO to 
finish this thing.

>
> > Given that the kdemacros.h file even gives specific instructions where to
> > put all the macros in the various kinds of type definitions, the script
> > could be even quite simple. It'd most probably also require adding the
> > macros also to all the places in the .h files though.
>
> Maybe library internal or private classes could be put in a separate
> namespace. This way, the version script could be just:
>
> {
> local:
>   extern "C++" {
>     KdeInternal::*;
>   };
> };
>
> or something similar.

 Right.

> PS. I am now trying a version script also for libkdecore. This one trims
> ~300 symbols from an overall of ~3500. However, I discovered that some of
> the "internal" symbols are in fact used by other libraries in kdelibs (at
> least in kio).

 Is the performance difference measurable?

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/