From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1322 invoked by alias); 31 Jul 2005 13:52:40 -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 1232 invoked by uid 22791); 31 Jul 2005 13:52:37 -0000 Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sun, 31 Jul 2005 13:52:37 +0000 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1DzEEn-0004kQ-WE for gcc@gcc.gnu.org; Sun, 31 Jul 2005 15:52:22 +0200 Received: from cpc1-macc1-3-0-cust53.bagu.cable.ntl.com ([81.97.76.53]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Jul 2005 15:52:21 +0200 Received: from mike by cpc1-macc1-3-0-cust53.bagu.cable.ntl.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 31 Jul 2005 15:52:21 +0200 To: gcc@gcc.gnu.org From: Mike Hearn Subject: Re: Symbol versions for inlined symbols Date: Sun, 31 Jul 2005 13:52:00 -0000 Message-ID: References: <20050731045749.GA17880@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) X-SW-Source: 2005-07/txt/msg01269.txt.bz2 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. >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 something more similar to Windows where a symbol lookup starting in libC checks libC, libstdc++.so.6, libD, app, libstdc++,so.5, libA, libB would work. That way, the GLOBAL WEAK symbols in the std namespace would always resolve to what you'd intuitively expect: the dependencies of that object. ELF compatibility would mostly be preserved as symbols could still be resolved to the parent and other objects in the image, but the chance of cross-wiring would be reduced. I think this is what the DT_1_GROUP flag is supposed to do, but for some reason it was never implemented in the glibc linker. Does anybody know why? Last time I talked about this with Michael Meeks at Novell, he seemed to think the semantics of the DT_1_GROUP flag would mess up C++ exception handling, which relies on the current ordering. Is that so? Oh, final thing - the GCC summit paper made it sound like only rare proprietary apps need the ability to mix multiple libstdc++ versions in the same image, but it's a very common thing to do for open source programs too: specifically, games. Games are why I'm asking, actually :) We already have nasty workarounds for this issue in place for NetPanzer, Lincity and a few other projects that distribute binaries and may be linked against other C++ libraries already on the system. The classic example is "C++ Game -> SDL -> SDL_audio -> libArts (for KDE audio) -> mismatched libstdc++ version -> crash in std::string". thanks -mike