[PATCH] dynamic_cast and gcc3

[Luis Pedro Coelho]

Em Quinta, 21 de Novembro de 2002 13:18, Michael Matz escreveu:
> Hi,
>
> On Wed, 20 Nov 2002, Luis Pedro Coelho wrote:
> > Is there a reason why programms are not being compiled with this flag
> > by default on the affected versions or was it just inertia?
>
> AFAICS there is no real reason.  We might want to measure the size impact
> on executables, and possibly startup time to know if we could do this
> unconditionally or only in special cases.

Just to get the feel of it, I linked kmail with this flag. (I just relinked, 
there is no need to recompile everything, is there?) Here is the size of the 
stripped binaries:

Without -Wl,-E (normal):
2027552 bytes.

With -Wl,-E:
2383168 bytes.

I don't know how to get good measurements of startup time.

This was done in a RH 7.3 setup, measuring kmail from CVS HEAD.

> That having said, I'm not sure that it would help in kview's case at hand.
> Because kview the executable is already only a wrapper exe around the
> kview.so DSO.  kview itself wouldn't provide those symbols anyway, and the
> DSO already does it, with or without -E.

>From what I understand (by watching make work), you create a library which 
contains the function main and then you link an empty program with this 
library.

When this programm is run, it loads another library through the KParts 
mechanism (which uses dlopen underneath). The problem is dynamic_casting 
symbols obtained from this other library.

I don't quite understand how this fits in with the examples given in g++ docs. 
Still, it says that dynamicly linked libraries are no problem from which I 
assume that symbol resolution is carried out to the full extent. Then it 
speaks of loading other libraries using dlopen: not only must you link the 
main programm with -Wl,-E you must also load the library with the RTDL_GLOBAL 
flag.

>From what I understand, you are using KPart::loadPlugins. Here is the call 
stack:

KImageViewer::Viewer::loadPlugins
KPart::Part::loadPlugins
KPart::Part::loadPlugin
KPart::ComponentFactory::createInstanceFromLibrary
KLibLoader::library
lt_dlopen
dlopen

KLibLoader::library, unlike KLibLoader::globalLibrary, does *not* use 
RTDL_GLOBAL. What I don't understand is how come the dynamic_cast<>s in 
createFactoryFromFactory (called from creat*FromLibrary) work while the ones 
outside do not. It also seems to me that if these casts fail, then no library 
code that calls KPart::Part::loadPlugin(s) will work. Or maybe I am just 
reading the code wrong.

Of course, changing something along this call stack to use RTDL_GLOBAL might 
have a very big impact on unforseen code.

I am sorry, but on my setup which uses g++ 2.96, I cannot test any of this.

HTH,
-- 
Luis Pedro Coelho

http://blogs.salon.com/0001523