From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7850 invoked by alias); 27 Oct 2002 21:46:04 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 7795 invoked by uid 71); 27 Oct 2002 21:46:03 -0000 Date: Sun, 27 Oct 2002 13:46:00 -0000 Message-ID: <20021027214603.7790.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Gabriel Dos Reis Subject: Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf Reply-To: Gabriel Dos Reis X-SW-Source: 2002-10/txt/msg01132.txt.bz2 List-Id: The following reply was made to PR libstdc++/8197; it has been noted by GNATS. From: Gabriel Dos Reis To: "Christian Ehrhardt" Cc: gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf Date: 27 Oct 2002 23:41:47 +0100 "Christian Ehrhardt" writes: | I got some more information on this one and a patch that fixes the | problem for me: Thanks for reporting more info on this issue. [...] | The problem seems to be that std::sin(float) is an inline function defined in | cmath. This inline function uses __builtin_sinf which in turn generates | a reference to a function sinf. | This function even exists and is exported from stubs.o: | | turing# nm sparc-sun-solaris2.9/libstdc++-v3/libmath/stubs.o |grep sinf | 00000714 T sinf | | However, in libstdc++.so the symbol sinf is private: Benjamin, Do we have infrastructure to export symbols based on target configurations? If not, does telling linker-map.gnu to export non-existing symbols an error? If not, is it documented to work as "expected"? Thanks, -- Gaby PS: I just realized I asked more questions that could provide any hints.