Define HAVE_ for math long double functions declared in vxworks headers

[Jonathan Wakely]

On 25/12/19 03:40 -0300, Alexandre Oliva wrote:
>
>When cross-building for vxworks, test for declarations of long double
>functions in math.h.  We don't normally test for these functions when
>cross compiling, because link tests don't work, or ever really, but
>not defining them as available causes replacements to be defined in
>ways that may cause duplicate definition linker errors if the units
>defining both the replacement and the actual implementation are
>brought in because of other symbols.
>
>Tested on trunk by checking configure results of libstdc++-v3 for an
>affected target, and also building natively on x86_64-linux-gnu.  Also
>tested for various cross configurations far more thoroughly on trees not
>matching trunk so closely.  I'm checking this in.
>
>
>libstdc++-v3/
>	* crossconfig.m4 (GLIBCXX_CROSSCONFIG) [*-vxworks*]: Define
>	long double functions as available if declared by math.h.
>	(GLIBCXX_CHECK_MATH_DECL, GLIBCXX_CHECK_MATH_DECLS): New.
>	* configure: Rebuild.
>---
> libstdc++-v3/configure      | 1104 +++++++++++++++++++++++++++++++++++++++++++
> libstdc++-v3/crossconfig.m4 |   62 ++
> 2 files changed, 1166 insertions(+)
>
>diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
>[omitted]
>diff --git a/libstdc++-v3/crossconfig.m4 b/libstdc++-v3/crossconfig.m4
>index 5e24889..2a0cb04 100644
>--- a/libstdc++-v3/crossconfig.m4
>+++ b/libstdc++-v3/crossconfig.m4
>@@ -291,9 +291,71 @@ case "${host}" in
>     AC_DEFINE(HAVE_SQRTF)
>     AC_DEFINE(HAVE_TANF)
>     AC_DEFINE(HAVE_TANHF)
>+
>+dnl # Different versions and execution modes implement different
>+dnl # subsets of these functions.  Instead of hard-coding, test for C
>+dnl # declarations in headers.  The C primitives could be defined as
>+dnl # macros, in which case the tests might fail, and we might have to
>+dnl # switch to more elaborate tests.
>+    GLIBCXX_CHECK_MATH_DECLS([
>+      acosl asinl atan2l atanl ceill cosl coshl expl fabsl floorl fmodl
>+      frexpl ldexpl log10l logl modfl powl sinl sinhl sqrtl tanl tanhl])
>+dnl # sincosl is the only one missing here, compared with the *l
>+dnl # functions in the list guarded by
>+dnl # long_double_math_on_this_cpu in configure.ac, right after
>+dnl # the expansion of the present macro.
>     ;;
>   *)
>     AC_MSG_ERROR([No support for this host/target combination.])
>    ;;
> esac
> ])
>+
>+
>+dnl
>+dnl Check to see if the (math function) argument passed is
>+dnl declared when using the c compiler
>+dnl
>+dnl Define HAVE_CARGF etc if "cargf" is declared
>+dnl
>+dnl argument 1 is name of function to check
>+dnl
>+dnl ASSUMES argument is a math function
>+dnl
>+dnl GLIBCXX_CHECK_MATH_DECL
>+AC_DEFUN([GLIBCXX_CHECK_MATH_DECL], [
>+  AC_CACHE_CHECK([for $1 declaration],
>+    [glibcxx_cv_func_$1_use], [
>+      AC_LANG_SAVE
>+      AC_LANG_C
>+      AC_TRY_COMPILE([
>+#include <math.h>
>+#ifdef HAVE_IEEEFP_H
>+# include <ieeefp.h>
>+#endif
>+], [
>+  void (*f)(void) = (void (*)(void))$1;

I wondered whether using ($1) here instead of just $1 would give any
benefit. It would mean that function-like macros are ignored.

Maybe it would be better to just do #undef $1 before the test, so that
all macros are ignored. That would match the actual usage, as <cmath>
does a #undef for each function.