From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21091 invoked by alias); 22 Apr 2009 09:13:10 -0000 Received: (qmail 21015 invoked by uid 48); 22 Apr 2009 09:12:53 -0000 Date: Wed, 22 Apr 2009 09:13:00 -0000 Message-ID: <20090422091253.21014.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libstdc++/39491] [4.4/4.5 regression] symbol __signbitl@GLIBCXX_3.4 in libstdc++ not exported anymore In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jakub at gcc dot gnu dot org" 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: 2009-04/txt/msg01897.txt.bz2 ------- Comment #13 from jakub at gcc dot gnu dot org 2009-04-22 09:12 ------- If hppa-linux has long double the same as double (which raises the question why it hasn't switched over to 128-bit long double together with powerpc*/sparc*/s390*/alpha back in 2006), then __NO_LONG_DOUBLE_MATH should be defined and therefore no code will ever reference __signbitl from signbit macro (and __signbitl isn't a supported API, so nothing should really care). If we really want to change libstdc++ (which I'm not sure about, can you find a single shared library or binary that references __signbitl from libstdc++.so?), then the patch should actually handle __signbitl by calling __signbit and also should be through .symver directive turned into @ symbol instead of @@ to make sure nothing newly linked can reference it from libstdc++.so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491