Hi,

On Sat, 19 May 2001, Simon Hausmann wrote:
> > 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 ;-)

Given enough time, I try to see everything ;-)
So: If we rely on GNU ld of a recent enough version it's possible (per
link maps) to make symbols private/public based on their name and
fileglobs, even by giving unmangled parts of the name (so something ala
"MyPrivateClass::*" is possible).  This has the added benefit (compared
with libtools -export-symbols-regex=... of libtool which only works
correctly on Solaris due to bugs in GNU ld) that those symbols then really
are private to the DSO, and so can theoretically be bound at link-time,
reducing the number of relocations, which would otherwise be necessary due
to ELF semantics if the symbols remain public.  I'm not sure in what
context the original question turned up on kdevelop-..., but I suspect not
to reduce the number of relocations.  What would be needed is a scanning
tool, that outputs namespace::class::method strings which should be
non-public.  This tool could be either directed by special comments (e.g.
to privatize a whole class, e.g. all internal KHTML classes), or by C++
syntax (e.g. all private: methods of all classes).  I never got around at
implementing this thing last year, cause I wasn't able to convinve myself,
that the number of reduced relocation really would be worth it.  If it's
needed for other reasons we might try again.  For this all to work our
build process needs some massaging, but that's details ;)


Ciao,
Michael.