[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_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
> 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
