Bug#169497: G++ 3.2 breakage on sparc

[Matthias Klose <doko@cs.tu-berlin.de>]

[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 <doko@cs.tu-berlin.de> 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