Bug 29304 - autoconf should be used in libjava to check for fabs, fabsf and scalbn
Summary: autoconf should be used in libjava to check for fabs, fabsf and scalbn
Status: UNCONFIRMED
Alias: None
Product: classpath
Classification: Unclassified
Component: classpath (show other bugs)
Version: 0.15
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: build
Depends on:
Blocks:
 
Reported: 2006-10-01 03:51 UTC by Jack Howarth
Modified: 2021-11-29 00:30 UTC (History)
5 users (show)

See Also:
Host: powerpc-apple-darwin8
Target: powerpc-apple-darwin8
Build: powerpc-apple-darwin8
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jack Howarth 2006-10-01 03:51:14 UTC
Currently libjava doesn't check for the existance of math functions in libm
before declaring them. This results in warnings on Darwin PPC...
symbol _fabsf used from dynamic library /usr/lib/libm.dylib(fabs.o) not from earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(sf_fabs.o)
symbol _fabs used from dynamic library /usr/lib/libm.dylib(fabs.o) not from earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(s_fabs.o)
symbol _scalbn used from dynamic library /usr/lib/libm.dylib(scalb.o) not from earlier dynamic library /sw/lib/gcc4/lib/libgcj.8.dylib(s_scalbn.o/sw/lib/odcctool
s/bin/ld: warning suggest use of -bind_at_load, as lazy binding may result in errors or different symbols being used
)
creating gappletviewer

We should be using wrappers like libgfortran/intrinsics/c99_functions.c does. In this case we need...

Index: classpath/native/fdlibm/sf_fabs.c
===================================================================
--- classpath/native/fdlibm/sf_fabs.c   (revision 117342)
+++ classpath/native/fdlibm/sf_fabs.c   (working copy)
@@ -19,6 +19,8 @@
 
 #include "fdlibm.h"
 
+#ifndef HAVE_FABSF
+#define HAVE_FABSF 1
 #ifdef __STDC__
        float fabsf(float x)
 #else
@@ -31,9 +33,12 @@
        SET_FLOAT_WORD(x,ix&0x7fffffff);
         return x;
 }
+#endif
 
 #ifdef _DOUBLE_IS_32BITS
 
+#ifndef HAVE_FABS
+#define HAVE_FABS 1
 #ifdef __STDC__
        double fabs(double x)
 #else
@@ -43,5 +48,6 @@
 {
        return (double) fabsf((float) x);
 }
+#endif
 
 #endif /* defined(_DOUBLE_IS_32BITS) */
Index: classpath/native/fdlibm/s_scalbn.c
===================================================================
--- classpath/native/fdlibm/s_scalbn.c  (revision 117342)
+++ classpath/native/fdlibm/s_scalbn.c  (working copy)
@@ -32,6 +32,8 @@ twom54  =  5.55111512312578270212e-17, /
 huge   = 1.0e+300,
 tiny   = 1.0e-300;
 
+#ifndef HAVE_SCALBN
+#define HAVE_SCALBN 1
 #ifdef __STDC__
        double scalbn (double x, int n)
 #else
@@ -63,3 +65,4 @@ tiny   = 1.0e-300;
         return x*twom54;
 }
 #endif /* _DOUBLE_IS_32BITS */
+#endif
Comment 1 Jack Howarth 2006-10-01 04:17:06 UTC
We will also need to add...

AC_CHECK_LIB([m],[fabsf],[AC_DEFINE([HAVE_FABSF],[1],[libm includes fabsf])])
AC_CHECK_LIB([m],[fabs],[AC_DEFINE([HAVE_FABS],[1],[libm includes fabs])])
AC_CHECK_LIB([m],[scalbn],[AC_DEFINE([HAVE_SCALBN],[1],[libm includes scalbn])])

to configure.ac in libjava.
Comment 2 Eric Gallager 2016-10-25 15:45:52 UTC
GCJ has been removed from GCC 7. So "wontfix"?
Comment 3 Andrew John Hughes 2016-10-25 17:25:38 UTC
No, this is a Classpath bug. Nothing to do with GCJ.
Comment 4 Eric Gallager 2019-01-02 21:43:00 UTC
(In reply to Andrew John Hughes from comment #3)
> No, this is a Classpath bug. Nothing to do with GCJ.

Does it make sense for Classpath and GCC to continue to share a bugzilla these days? This is far from the only time I've been confused by it... would it be possible to split them into 2 separate bug databases?
Comment 5 Andrew Pinski 2019-01-02 21:48:54 UTC
(In reply to Eric Gallager from comment #4)
> (In reply to Andrew John Hughes from comment #3)
> > No, this is a Classpath bug. Nothing to do with GCJ.
> 
> Does it make sense for Classpath and GCC to continue to share a bugzilla
> these days? This is far from the only time I've been confused by it... would
> it be possible to split them into 2 separate bug databases?

I am less confused by the sharing because I know the history (I was one of the folks who prompted the sharing).  I don't think it hurts having the classpath in GCC's bugzilla and I normally monitor classpath's bug list for accidental usage there (there was one today but it only happens once every two months so it is low traffic).