From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19224 invoked by alias); 27 Oct 2002 22:36:00 -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 19200 invoked by uid 71); 27 Oct 2002 22:36:00 -0000 Date: Sun, 27 Oct 2002 14:36:00 -0000 Message-ID: <20021027223600.19198.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Phil Edwards Subject: Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf Reply-To: Phil Edwards X-SW-Source: 2002-10/txt/msg01138.txt.bz2 List-Id: The following reply was made to PR libstdc++/8197; it has been noted by GNATS. From: Phil Edwards To: Gabriel Dos Reis Cc: Christian Ehrhardt , gcc-gnats@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf Date: Sun, 27 Oct 2002 17:34:02 -0500 Answering because I happen to have just checked my mail: On Sun, Oct 27, 2002 at 11:41:47PM +0100, Gabriel Dos Reis wrote: > Do we have infrastructure to export symbols based on target > configurations? We need to, but we don't yet. > If not, does telling linker-map.gnu to export > non-existing symbols an error? No, it's no problem. See for example the multiple entries for size_t: only one of them will actually be used, depending on the architecture. > If not, is it documented to work as > "expected"? Probably not documented, but anything marked as exported that doesn't exist in the final library is just ignored. That is, the symbols may be exported, but they aren't expected. :-) Phil -- I would therefore like to posit that computing's central challenge, viz. "How not to make a mess of it," has /not/ been met. - Edsger Dijkstra, 1930-2002