RTLD_GLOBAL again (was Re: kdeutils/kregexpeditor/test)

[Michael Matz]

Hi,

there's basically no mean to ensure, that 3rd party libs don't produce
symbol clashes with RTLD_GLOBAL, except postprocessing them with a program
fiddling with symbol visibility (_and_ relocating the lib at the same
time, in case it used some of it's own global symbols, which we want to
get rid of), or at link time of that lib, which by definition isn't
possible for us for 3rd party libs.  Also this is only possible on some
binary formats, notably ELF.

Filters can be used theoretically to export only a subset of symbols,
while still binding them to the filtered library.  But that feature is ELF
only, and was designed for C.  I'm not sure, and haven't tested if/how it
works with C++, esp. regarding those implemenation dependent symbols used
to implement C++, e.g. RTTI or virtual table.  I think it would be fairly
difficult (I rather think it's impossible) to provide those in the filter,
without introducing the problem of again exporting the whole class.
Maybe for C libraries they're enough, although we don't have problems with
them. I'm also not sure, how new the support for filter's is in glibc's
ld.so (and I don't know, if the BSD's (besides Solaris) even provide it),
and how it behaves in connection with dlopening such a filter (compared to
linking against one).  I.e. I think filter are not an option for us, too.
... Ohh, I just tried them.  They can't be dlopen'ed at all (not even, if
the dlopen'ed thing only _link_ against a filter, but isn't itself one).
So screw all that.

Still, the problem remains, that RTLD_LOCAL is not the ideal.  We could
start to make the probability of having that problem smaller.  Put all of
KDE into K* namespaces (alternatively to prefix _all_ non-nested classes
with "K").  Provide a mean in the .desktop files to mark
"trusted" plugins.  Those would be loaded _GLOBAL, while all other only
_LOCAL.  Basically a plugin linking to _any_ 3rd party lib (except some
carefully chosen ones) can't be trusted.  That's the case even if it only
possibly links against a lib (say depending on if it's installed at build
time), to not have to create the .desktop file on the fly.

And we can "register" known namespaces for other people, maintaining
uniqueness, so also helping third parties.  Those which don't use this
simply are then in error, if really a clash happens.


Ciao,
Michael.