From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6642 invoked by alias); 31 Jul 2005 15:34:14 -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 6620 invoked by uid 22791); 31 Jul 2005 15:34:11 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 31 Jul 2005 15:34:11 +0000 Received: from drow by nevyn.them.org with local (Exim 4.52) id 1DzFpK-0007RM-2H; Sun, 31 Jul 2005 11:34:10 -0400 Date: Sun, 31 Jul 2005 15:34:00 -0000 From: Daniel Jacobowitz To: Mike Hearn Cc: gcc@gcc.gnu.org Subject: Re: Symbol versions for inlined symbols Message-ID: <20050731153410.GA28517@nevyn.them.org> Mail-Followup-To: Mike Hearn , gcc@gcc.gnu.org References: <20050731045749.GA17880@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-07/txt/msg01270.txt.bz2 On Sun, Jul 31, 2005 at 03:53:42PM +0100, Mike Hearn wrote: > On Sun, 31 Jul 2005 00:57:49 -0400, Daniel Jacobowitz wrote: > > You may wish to read the proceedings from this year's GCC summit, where > > another solution was presented by some gentlemen from Intel. For various > > reasons, symbol versioning is not a useful solution to this problem. > > I hadn't seen that, thanks. It's an interesting approach but a bit > confusing to somebody like me who doesn't use C++ very often: it sounded > from their writeup like you'd have to modify application code, and then in > other parts it sounded like actually only the libstdc++ headers would need > to be modified and apps would do the right thing transparently. The latter is the whole point. > From my perspective the most convenient solution would be a way to modify > ELF symbol scoping (which is what symbol versioning does, in a complicated > sort of way). Instead of starting lookup for a symbol in libC from app, > going on through libstdc++.so.5, libA, libB, libC, libstdc++.so.6, libD: > > app > libstdc++.so.5 > libA, > libB, > libC, > libstdc++.so.6 > libD You've completely missed the problem here, I'm afraid. You can't use anything like symbol scoping to do this, because the generated symbols will end up in the application and in libC. Besides, what if libC ends up being a static library using libstdc++.so.5 and you want to rebuild app? Solving this little bit of the problem just isn't worth it. -- Daniel Jacobowitz CodeSourcery, LLC