From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19032 invoked by alias); 23 Apr 2009 16:55:23 -0000 Received: (qmail 17843 invoked by uid 48); 23 Apr 2009 16:55:07 -0000 Date: Thu, 23 Apr 2009 16:55:00 -0000 Message-ID: <20090423165507.17842.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: "bkoz 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/msg02185.txt.bz2 ------- Comment #22 from bkoz at gcc dot gnu dot org 2009-04-23 16:55 ------- >The hppa port sets long-double-fcts = no in glibc > and this causes all the aliases to be created, otherwise you'd never > be able to link anything that used `l' ending math functions. Defining > __NO_LONG_DOUBLE_MATH is just another step in the right direction to > avoid using long double functions, and use the double functions instead. It seems to me like setting long-double-fcts = no in glibc should automatically define __NO_LONG_DOUBLE_MATH.... right? Anyway. >>From the .so range listed in #18 it looks like this was a regression in 4.2/4.3, perhaps related to C library changes. There was a __signbitl export in gnu.ver. gcc-3.4.6 __signbitl in GLIBCXX_3.4 gcc-4.1.2 __signbitl in GLIBCXX_3.4 gcc-4.2.4 __signbitl in GLIBCXX_3.4 gcc-4.3 __signbitl in GLIBCXX_3.4 So that's how it leaked out of libstdc++ so's. However, this symbol was never actually defined, exported and placed in the abi baseline for hppa-linux-gnu, inclusive gcc-3.4 to trunk. Or any other platform. Thus, why it was removed from gnu.ver, mistakenly as it turns out. . It would be my inclination to fix glibc and then alias as per Jakub's #13 comment for hppa-linux only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39491