This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Large, modular C++ application performance ...
- From: "H. J. Lu" <hjl at lucon dot org>
- To: michael meeks <michael dot meeks at novell dot com>
- Cc: Giovanni Bajo <rasky at develer dot com>, gcc at gcc dot gnu dot org
- Date: Mon, 1 Aug 2005 08:55:17 -0700
- Subject: Re: Large, modular C++ application performance ...
- References: <1122666555.19624.25.camel@linux.site> <019e01c5950b$a7ddff90$bf03030a@trilan> <1122889126.19623.105.camel@linux.site>
On Mon, Aug 01, 2005 at 10:38:46AM +0100, michael meeks wrote:
> 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:
>
Since you were comparing Windows vs. ELF, doesn't Windows need a file
to define which symbols to export for a shared library? Why can't you
you do it with ELF using a linker map? Libstdc++.so is built with
a linker map. Any C++ shared library should use one if the startup
time is a big concern. Of coursee, if gcc can generate a list of
symbols suitable for linker map, which needs to be exported, it will
be very helpful. I don't think it will be too hard to implement.
H.J.