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.
