Hi Giovanni,
On Sat, 2005-07-30 at 15:36 +0200, Giovanni Bajo wrote:
> I'm slow, but I can't understand why a careful design of the interfaces of
> the dynamic libraries
Well - sure, depends how 'careful' you are ;-) clearly if no C++
classes with virtual methods form the interface of any library, then
there is no problem ;-) unfortunately, mandating that would rather
cripple C++.
> together with the new -fvisibility flags, should not
> be sufficient. It worked well in other scenarios
-fvisibility is helpful - as the paper says, not as helpful as the old
-Bsymbolic (or link maps exposing only 3 or so functions) were. However
- -fvisibility can only help so much - if you have:
class LibraryAClass {
virtual void doFoo(void);
};
class LibraryBClass : public LibraryAClass {
virtual void doBaa(void);
};
then there are 2 problems:
a) there is no symbol visibility that will trigger internal
binding in addition to a symbol export. ie. if
'LibraryBClass' is a public interface - no useful
visibility markup can be done; and hence we have a named
relocation for 'doBaa's vtable slot.
[ IMHO this is a feature-gap, we need a new ('export'?)
visibility attribute for this case ].
b) even if LibraryBClass is a 'hidden' class - to build it's
vtable we have to have a slot for 'doFoo' which is in
an external library (A) => another named relocation. An
unavoidable consequence of using virtual classes as part of
a library's API.
> IMHO, it's unreasonable to break the C++ ABI for 1 second of warm time
> startup.
Well - it's an option that was considered, although - as you say -
highly unpleasant, and probably quite unnecessary - as the paper
explains.
Regards,
Michael.
--
[EMAIL PROTECTED] <><, Pseudo Engineer, itinerant idiot
