This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf
- From: Phil Edwards <phil at jaj dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 27 Oct 2002 22:36:00 -0000
- Subject: Re: libstdc++/8197: std::sin(float) causes undefined reference to sinf
- Reply-to: Phil Edwards <phil at jaj dot com>
The following reply was made to PR libstdc++/8197; it has been noted by GNATS.
From: Phil Edwards <phil@jaj.com>
To: Gabriel Dos Reis <gdr@integrable-solutions.net>
Cc: Christian Ehrhardt <ehrhardt@mathematik.uni-ulm.de>, 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