libstdc++: abi_check fails due to lacking long double arithmetic functions

[Andreas Krebbel]

Hi,

the gcc 4.1 testsuite currently shows a failure for the libstdc++ abi_check testcase
on s390 and s390x and I see this one failing on several other targets as well.

On s390x abi_check complains about 22 missing functions in libstdc++.so:

FUNC:acosl@@GLIBCXX_3.4.3
FUNC:asinl@@GLIBCXX_3.4.3
FUNC:atan2l@@GLIBCXX_3.4
FUNC:atanl@@GLIBCXX_3.4.3
FUNC:ceill@@GLIBCXX_3.4.3
FUNC:coshl@@GLIBCXX_3.4
FUNC:cosl@@GLIBCXX_3.4
FUNC:expl@@GLIBCXX_3.4
FUNC:floorl@@GLIBCXX_3.4.3
FUNC:fmodl@@GLIBCXX_3.4.3
FUNC:frexpl@@GLIBCXX_3.4.3
FUNC:hypotl@@GLIBCXX_3.4
FUNC:ldexpl@@GLIBCXX_3.4.3
FUNC:log10l@@GLIBCXX_3.4
FUNC:logl@@GLIBCXX_3.4
FUNC:modfl@@GLIBCXX_3.4.3
FUNC:powl@@GLIBCXX_3.4
FUNC:sinhl@@GLIBCXX_3.4
FUNC:sinl@@GLIBCXX_3.4
FUNC:sqrtl@@GLIBCXX_3.4
FUNC:tanhl@@GLIBCXX_3.4
FUNC:tanl@@GLIBCXX_3.4


I think this only happens when building gcc 4.1 on a host with glibc 2.4 installed. abi_check
started failing around the time I've upgraded glibc on our gcc daily build.

Here is what I found out about it:

1. Works with older glibc:
When gcc is built on a machine with glibc 2.3.x no long double arithmetic functions are
exported by glibc. The libstdc++ configure script figures that out and libmath/stubs.c
generates wrapper functions calling the double versions of these functions. The resulting
libstdc++ has the above symbols and abi_check is happy.

2. Works with gcc 4.2 and higher:
Jakub made a patch for compatility.cc in libstdc++ providing wrapper functions.
These become active when _GLIBCXX_LONG_DOUBLE_COMPAT is defined by configure for targets
which have to support long-double-64 AND long-double-128. So we again have these wrapper functions
and abi_check succeeds.

3. Doesn't work with gcc 4.1 and glibc 2.4:
Since Jakubs patch hasn't been applied to gcc 4.1 branch these symbols are simply lacking. I'm not sure
whether thats a serious problem or not. A libstdc++ without the long double functions implies usage
of glibc 2.4 so a binary needing such a function then uses the glibc version - right?!

So if thats no problem at all I think we should regenerate the gcc 4.1 baseline_symbols.txt 
for the affected targets in order to make abi_check happy again.

Bye,

-Andreas-