Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC 3.0.3: Bugs to Fix]) (fwd)

[Nathan Sidwell <nathan at codesourcery dot com>]

Waldo Bastian wrote:

> That's pretty bad because loading (dlopen'ing) parts with RTLD_GLOBAL is
> asking for trouble. There is no way that we can guarantee that one part
> doesn't by chance use the same name for some class/symbols as another part,
> since parts may get developed independently of each other.
> 
> We are already running into trouble with the flash plugin colliding with
> OpenGL (both define "DisplayList") and things like this aren't helping the
> situation.
Other than reiterating what Joe Buck said, what you describe sounds
like a job for namespaces. Ok, so you'd have to retrofit them - but
you've got to do something retroactively anyway.  If you cannot do that
then you might be able to do some linker symbol remapping. For instance,
a) all the classes you wish to be dcastable/throwable across shared library
boundaries should be placed in the 'ReallyGlobal' namespace (for want of a
better name :-)
b) when building the shared library prefix any symbol which is not an
export or import to/from the library and not in the ReallyGlobal namespace
with 'PrivateToLibFoo'

That sounds tricky to me, but as Joe pointed out - you've broken the one
definition rule and 'magically' want the compilation system to know which
multiply defined objects are the same and which are different.

Dirk Mueller wrote:
> Point taken for the RTLD_GLOBAL part, but why do we need RTLD_NOW in order
> to make RTTI work, as the original posting pointed out ?
You should be able to do it lazily too.

But, RTLD_GLOBAL doesn't work on (at least) gnu.linux i86 (see gcc bug 4993).
I've not had time to investigate further, but aim to do so shortly.

nathan

-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
         'But that's a lie.' - 'Yes it is. What's your point?'
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org