I have a library (commoncpp2) which defines the symbol _XOPEN_SOURCE (automatically by configure-script) When including <cmath> the compiler reports: In file included from bug.cpp:7: /usr/local/lib/gcc-lib/i386-portbld-freebsd4.6/3.1.1/include/g++-v3/cmath: In function `float std::acos(float)': /usr/local/lib/gcc-lib/i386-portbld-freebsd4.6/3.1.1/include/g++-v3/cmath:99: `:: acosf' undeclared (first use here) ... and a lot more error messages about undefined float functions Release: 3.1.1 FreeBSD Environment: System: FreeBSD ws-ew-3.demig 4.6-STABLE FreeBSD 4.6-STABLE #6: Mon Aug 12 08:56:03 CEST 2002 nk@ws-ew-3.demig:/usr/src/sys/compile/WSEW3 i386 host: i386-portbld-freebsd4.6 build: i386-portbld-freebsd4.6 target: i386-portbld-freebsd4.6 configured with: ./..//gcc-3.1.1/configure --disable-nls --with-gnu-as --with-gnu-ld --with-gxx-include-dir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.6/3.1.1/include/g++-v3 --with-system-zlib --includedir=/usr/local/lib/gcc-lib/i386-portbld-freebsd4.6/3.1.1/include/Java --enable-shared --enable-threads --enable-threads=posix --prefix=/usr/local i386-portbld-freebsd4.6 How-To-Repeat: see enclosed file bug.cpp
Fix: math.h as fixincluded from freebsd's /usr/include contains this: #if ! defined (_XOPEN_SOURCE) ... definition of float functions #endif cmath contains this: #if _GLIBC_HAVE_ACOSF extern acosf() ... #endif Either FreeBSD's math.h is wrong in assuming that the float functions do not conform to xopen or the symbol _GLIBC_HAVE_ACOSF should be defined differently. BTW: the float functions DO exist in libc.so.
Responsible-Changed-From-To: unassigned->ljrittle Responsible-Changed-Why: Mine.
State-Changed-From-To: open->analyzed State-Changed-Why: This is a well-known issue (and not just with FreeBSD). Although (1) it is a bug with the configure script itself to test for "feature macros" in a different context than will be used, (2) it is a libstdc++-v3 bug to not adapt to visibility of the underlying libc. I have assigned myself (and left it open) since I am reworking this aspect of the C++ library. I suspect that even after I fix (2), (1) will still present a problem for some software packages. I can confirm that this bug still exists in 3.2.2 and mainline. Thanks for the report.
State-Changed-From-To: analyzed->closed State-Changed-Why: Patch on mainline (will be in 3.4). Not a regression from any 3.0 release.
State-Changed-From-To: closed->open State-Changed-Why: Reopen: Since in stage 3 for 3.3 branch, real bug fixes are still OK even if not regression from past release. Fix will be moved to the 3.3 branch as soon as tested in that context.
State-Changed-From-To: open->closed State-Changed-Why: Patch applied to 3.3 branch.
*** Bug 10993 has been marked as a duplicate of this bug. ***