[ok, this is a Debian self made problem, so don't read on ...] The cause is the patch we apply to build a compiler for sparc-linux, supporting -m64 as well. In the configury, the _GLIBCPP_HAVE_<func>L detect the /lib64/libc.so.6 ...
The testcase in #169497 works fine when compiled with g++-3.2 -m64. Not sure why s390/s390x doesn't experience similiar problems ... I will disable sparc64 support for the next upload. this is the last bug before we can begin the gcc-3.2/g++-3.2 transition. So the safe way seems to be to build the C compiler twice to provide a 64bit compiler for sparc. Anyone on debian-sparc to take care of that or fix the multilib build? Matthias Martin v. Loewis writes: > Matthias Klose <[EMAIL PROTECTED]> writes: > > > ok, I'm forwarding this to Martin and Phil, two upstream developers > > (hopefully still ;-) listening on debian-gcc. > > I would suggest that the libstdc++ autoconf test should be enhanced: > _GLIBCPP_HAVE_ACOSL should not be defined if no prototype is > available. I'm not quite sure though why the test program passes. > AFAICT, it tries to compile > > #include <math.h> > int main() > { > acosl(0); > } > > That is compiled using g++. > > I'd be curious whether this compiles; it should not because no > prototype is declared for acosl. > > If it does compile, the reason should be understood; if it is a good > reason, the test program should be modified to detect that no > prototype is available. > > If this code does not compile, it should be investigated why configure > still defines _GLIBCPP_HAVE_ACOSL. > > I don't have the time to design a patch, but the relevant macros is > GLIBCPP_CHECK_MATH_DECL_AND_LINKAGE_1, from libstdc++/acinclude.m4. > > Regards, > Martin