This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Jakub Jelinek <jakub@redhat.com> wrote:
> > If you want dynamic cast (and that's just one thing) to work with dlopen in
> > gcc3+, you need to use RTLD_GLOBAL. (Don't get confused by Nathan not
> > understanding what if and only if means).

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.

But that causes an interesting problem.  You say that you don't want to
use RTLD_GLOBAL because someone might duplicate a class name (say,
"DisplayList").  Of course, this violates the one-definition rule, but
let's ignore that for a moment.

But if you want to allow multiple definitions of the same class, then
I don't see what

	dynamic_cast<DisplayList*>(foo)

is supposed to mean.  One possible definition is for the strings of all
base classes of foo to be checked for a match.  But what if that turns out
to be a different DisplayList than the one the current compilation unit
knows about?  Also there is a speed penalty to be paid if we must do this
string-compare, possibly a substantial one.  Certainly there are hashing
techniques that could be used to make the lookup faster, but we're between
a rock and a hard place: we signed up to implement a standard ABI that
multiple compiler vendors agreed on, and it puts constraints on the RTTI
implementation.  Even if the g++ team agrees to solve it for you, it would
just mean that KDE can't be built by the other compilers, like Intel's,
SGI's, or HP's.

> The alternative, banning RTTI from KDE, isn't very attractive either.

What if you only use RTLD_GLOBAL for those libraries that define base
classes that you'll want to do RTTI with?  Or use it everywhere except
with libraries that you know are problematic and sloppy with name spaces,
like the flash plugin and OpenGL.




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]