From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1425 invoked by alias); 1 Aug 2005 15:55:24 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 1412 invoked by uid 22791); 1 Aug 2005 15:55:21 -0000 Received: from smtp114.sbc.mail.mud.yahoo.com (HELO smtp114.sbc.mail.mud.yahoo.com) (68.142.198.213) by sourceware.org (qpsmtpd/0.30-dev) with SMTP; Mon, 01 Aug 2005 15:55:21 +0000 Received: (qmail 14603 invoked from network); 1 Aug 2005 15:55:19 -0000 Received: from unknown (HELO lucon.org) (hjjean@sbcglobal.net@69.232.224.217 with login) by smtp114.sbc.mail.mud.yahoo.com with SMTP; 1 Aug 2005 15:55:19 -0000 Received: by lucon.org (Postfix, from userid 1000) id 78F4764552; Mon, 1 Aug 2005 08:55:17 -0700 (PDT) Date: Mon, 01 Aug 2005 15:55:00 -0000 From: "H. J. Lu" To: michael meeks Cc: Giovanni Bajo , gcc@gcc.gnu.org Subject: Re: Large, modular C++ application performance ... Message-ID: <20050801155517.GA5095@lucon.org> References: <1122666555.19624.25.camel@linux.site> <019e01c5950b$a7ddff90$bf03030a@trilan> <1122889126.19623.105.camel@linux.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1122889126.19623.105.camel@linux.site> User-Agent: Mutt/1.4.1i X-SW-Source: 2005-08/txt/msg00027.txt.bz2 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.