[I don't think it's off-topic at all] Linking speed for C++

[Joe Buck]

> > What will this required dynamic relocation do?
> 
> Allow the symbol to be overridden from another DSO earlier in
> the symbol resolution search path.

OK, OK (and thanks to the other 5-6 people who told me this as well).
This feature, unfortunately, is quite expensive.

It seems the only way out that preserves the ability to override symbols,
but that gets rid of the relocations, is to have stubs for all calls.
That is, the function pointer can be replaced by

(stub_address - vtable_address) 

and the stub can, in turn, be a normal PIC call (or, depending on the
details of PIC on the particular processor, just a jump).  This would seem
to get rid of all the relocations for the vtable, but at a subtantial
cost.  Some alternate redesign of the vtable would probably be better.

(Yes, this kind of thing will break the standard ABI).

Or, of course, just break the ability to overload symbols for virtual
functions. :-)  The user waiting for his desktop to start up may not
care.