From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13239 invoked by alias); 16 Feb 2012 20:09:09 -0000 Received: (qmail 13228 invoked by uid 22791); 16 Feb 2012 20:09:08 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 16 Feb 2012 20:08:55 +0000 From: "ro at CeBiTec dot Uni-Bielefeld.DE" To: gcc-bugs@gcc.gnu.org Subject: [Bug libstdc++/52188] [4.7 regression] IPA-CP change broke libstdc++ symbol versioning on Solaris Date: Thu, 16 Feb 2012 20:20:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libstdc++ X-Bugzilla-Keywords: X-Bugzilla-Severity: major X-Bugzilla-Who: ro at CeBiTec dot Uni-Bielefeld.DE X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: ro at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.7.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-02/txt/msg01718.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52188 --- Comment #11 from ro at CeBiTec dot Uni-Bielefeld.DE 2012-02-16 19:58:27 UTC --- > --- Comment #7 from Jakub Jelinek 2012-02-10 12:30:39 UTC --- > The bug was that the gnu.ver wildcards were too generic and thus matched even > something that wasn't intended to be exported and just happened to be exported > as an implementation detail. > This caused a problem on Linux several years ago (I think in 2005), and since > then these are forcefully exported from compatibility.cc: [...] > but not on Solaris, because it either doesn't support GNU symver, or doesn't > have corresponding runtime support. ld.so.1 lacks the runtime support, and likely won't get it any time soon. > I think the bug is not on the optimization side, it is fine if the > optimizations change stuff that are implementation details, C++ isn't a very > good language for ABI stability and just requires lots of work on the libstdc++ > side to preserve at least some. > > So, I'd say it is time to preprocess the *.ver files and tweak them based on > target OS or its version, and additionally you'll want (for Solaris) enable the That's what my proposed patch does. What do you think about it? > above hunk (sans the following stuff), to make sure it doesn't go again when > the optimizers change. Given that they weren't present in 4.6, the first release with versioned libstdc++.so on Solaris, I think it's easier to simply keep them unexported, as Richard suggested. Rainer