[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: KDE hackers, please read (was [nathan@codesourcery.com: Re: GCC
From:       Joe Buck <jbuck () synopsys ! COM>
Date:       2001-12-10 19:14:30
[Download RAW message or body]

> 
> >    3) Persuade gcc folks to add compiler switch that makes gcc use string
> > comparing when doing rtti, and simply compile whole KDE with this switch
> > turned on.

Mark writes:
> All code in the application -- including the C++ run-time library --
> needs to be compiled the same way, so you would have to rebuild
> everything to do this.

In this case, that isn't clear to me.  All code needs to be compiled the
same way if the flag in question produces an incompatible ABI, but I'm
not sure it would necessarily be true in this case.  It might be possible
to have a design that would only require special treatment for code
containing RTTI operations where types cross a dynamic library boundary,
but to still use the same standard library.

Just the same, it's not reasonable for the KDE folks to expect the gcc
folks to design such a feature for them.  It's not C++.  KDE isn't going
to work with any of the other x86-on-Linux compilers either (SGI, Intel)
if it requires such a feature.

> Mixing C++ and dlopen w/o RTLD_GLOBAL is fundamentally wrong.

This goes too far.  In many cases it is very useful; we certainly used the
technique heavily in the Ptolemy project, and made it work on many Unix
flavors plus Windows (however, the use was more restricted: it allowed the
dynamic loading of derived classes for which the base classes were already
in the core application with globally available symbols, and builtin RTTI
operations like dynamic_cast were not used).

What's broken in the KDE case is that two contradictory things are being
requested: RTTI assuming a global type system, and dynamic loading
assuming private type systems.
[prev in list] [next in list] [prev in thread] [next in thread]