version script for libkdeui

[Luciano Montanaro]

On Monday 15 March 2004 15:03, Lubos Lunak wrote:
> 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 ;).

Can you explain a bit more? What is --enable-nmcheck supposed to do?
Maybe I can still help. Although I suspect you want me to sieve through 
the headers to find and mark internal methods...

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

But these macros should be used for methods of classes whose interface is 
intended to be exported, and a namespace to mark internal classes.
Hiding a whole class would be a relatively small work, hiding a conspicuous 
number of symbols, while finding internal methods in otherwise exported interfaces
would need patience and deeper knowledge of the classes. So, to test the waters,
I'd start with the namespace work. 

>  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?
> 

I can't perceive on my home computer. I'll try to get some number when I get back
near it, next weekend.

I'll try to "LD_DEBUG=statistics konqueror" a few times with and without 
the version scripts enabled. Is there some better test out there?

Luciano