gsl 0.8 compile error

gsl 0.8 compile error

[Ãֱ⿵]

I have tried to compile gsl 0.8 at OpenBSD 2.9/sparc
But I gained this error messge. 

gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -c fp.c  -fPIC -DPIC -o .libs/fp.lo
In file included from fp.c:26:
fp-freebsd.c: In function `gsl_ieee_set_mode':
fp-freebsd.c:27: syntax error before `prec'
fp-freebsd.c:34: `prec' undeclared (first use in this function)
fp-freebsd.c:34: (Each undeclared identifier is reported only once
fp-freebsd.c:34: for each function it appears in.)
fp-freebsd.c:34: `FP_PS' undeclared (first use in this function)
fp-freebsd.c:38: `FP_PD' undeclared (first use in this function)
fp-freebsd.c:42: `FP_PE' undeclared (first use in this function)
fp-freebsd.c:50: `rnd' undeclared (first use in this function)
fp-freebsd.c:72: `mode' undeclared (first use in this function)
fp-freebsd.c:72: `FP_X_DNML' undeclared (first use in this function)
*** Error code 1

Stop in /home/I01/xenus/gsl-0.8/ieee-utils.
*** Error code 1

Stop in /home/I01/xenus/gsl-0.8 (line 356 of Makefile).
*** Error code 1

Stop in /home/I01/xenus/gsl-0.8 (line 486 of Makefile).


What is this meaning?

-- 
===========================================================
Ki-young, CHOI    : xenus@physics.hanyang.ac.kr
PHYSICS dept. HYU : http://physics.hanyang.ac.kr
HOME PHONE        : +82-2-2298-1807
CELLULAR          : +82-11-9987-8666
HOMEPAGE          : http://physics.hanyang.ac.kr/~xenus
===========================================================
We run GNU!
http://korea.gnu.org

Re: gsl 0.8 compile error

[Brian Gough]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]

Ãֱ⿵ writes:
 > I have tried to compile gsl 0.8 at OpenBSD 2.9/sparc
 > But I gained this error messge. 
 > 
 > gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -O2 -c fp.c  -fPIC -DPIC -o .libs/fp.lo
 > In file included from fp.c:26:
 > fp-freebsd.c: In function `gsl_ieee_set_mode':
 > fp-freebsd.c:27: syntax error before `prec'
 > fp-freebsd.c:34: `prec' undeclared (first use in this function)
 > fp-freebsd.c:34: (Each undeclared identifier is reported only once
 > fp-freebsd.c:34: for each function it appears in.)
 > fp-freebsd.c:34: `FP_PS' undeclared (first use in this function)
 > fp-freebsd.c:38: `FP_PD' undeclared (first use in this function)
 > fp-freebsd.c:42: `FP_PE' undeclared (first use in this function)
 > fp-freebsd.c:50: `rnd' undeclared (first use in this function)
 > fp-freebsd.c:72: `mode' undeclared (first use in this function)
 > fp-freebsd.c:72: `FP_X_DNML' undeclared (first use in this function)
 > *** Error code 1
 > 

Thanks for reporting that problem.  At the configure stage the
configure script defaults to using the ieee file for Freebsd for any
unknown BSD system (we don't have a corresponding file for Openbsd).

If you could find out what functions Openbsd uses to control rounding
mode and precision that could be added. 

To work around the problem edit the file config.h and comment out the
line,

#define HAVE_FREEBSD_IEEE_INTERFACE 1

and you should then be able to compile the rest of the library.

regards
Brian Gough

Re: gsl 0.8 compile error

[Toby White]

Brian Gough <bjg@network-theory.co.uk> writes:

> Thanks for reporting that problem.  At the configure stage the
> configure script defaults to using the ieee file for Freebsd for any
> unknown BSD system (we don't have a corresponding file for Openbsd).
> 
> If you could find out what functions Openbsd uses to control rounding
> mode and precision that could be added. 

I'd been meaning to do this for a while - this got me round to it. 
Anyway - the OpenBSD IEEE interface is identical to (indeed, 
originally lifted straight from) the NetBSD one (which is the same 
as FreeBSD, except without any precision control). 

(At least on i386-based openbsd - but from the openbsd source it 
looks the same for all other architectures)

The patches below fix it - however, make check throws up a couple
of errors - I've addressed these in a separate post. This has 
only been tested on OpenBSD 2.9, but should work for any version
after 2.0.

The following patch is the simplest way to fix it:

--- configure Wed May 23 10:37:27 2001
+++ configure.new       Mon Jun 25 17:27:53 2001
@@ -6562,7 +6562,11 @@
         cat >> confdefs.h <<\EOF
 #define HAVE_NETBSD_IEEE_INTERFACE 1
 EOF
-
+       ;;
+    *-*-openbsd*)
+       cat >> confdefs.h <<\EOF
+#define HAVE_NETBSD_IEEE_INTERFACE 1
+EOF
         echo "$ac_t""netbsd" 1>&6 
         ;;
     *-*-*bsd*)

But you probably actually want to have correct error messages; so
the following is better:

--- configure Wed May 23 10:37:27 2001
+++ configure.new       Mon Jun 25 17:27:53 2001
@@ -6562,7 +6562,11 @@
         cat >> confdefs.h <<\EOF
 #define HAVE_NETBSD_IEEE_INTERFACE 1
 EOF
-
+       ;;
+    *-*-openbsd*)
+       cat >> confdefs.h <<\EOF
+#define HAVE_OPENBSD_IEEE_INTERFACE 1
+EOF
         echo "$ac_t""openbsd" 1>&6 
         ;;
     *-*-*bsd*)


--- fp.c      Mon Jun 25 17:38:23 2001
+++ fp.c.new    Mon Jun 25 17:38:38 2001
@@ -28,6 +28,8 @@
 #include "fp-os2emx.c"
 #elif defined(HAVE_NETBSD_IEEE_INTERFACE)
 #include "fp-netbsd.c"
+#elif defined(HAVE_OPENBSD_IEEE_INTERFACE)
+#include "fp-openbsd.c"
 #elif defined(HAVE_DARWIN_IEEE_INTERFACE)
 #include "fp-darwin.c"
 #else

--- fp-netbsd.c Wed Apr 18 22:52:28 2001
+++ fp-openbsd.c        Mon Jun 25 17:33:45 2001
@@ -31,15 +31,15 @@
   switch (precision)
     {
     case GSL_IEEE_SINGLE_PRECISION:
-      GSL_ERROR ("NetBSD only supports default precision rounding",
+      GSL_ERROR ("OpenBSD only supports default precision rounding",
                 GSL_EUNSUP);
       break;
     case GSL_IEEE_DOUBLE_PRECISION:
-      GSL_ERROR ("NetBSD only supports default precision rounding",
+      GSL_ERROR ("OpenBSD only supports default precision rounding",
                 GSL_EUNSUP);
       break;
     case GSL_IEEE_EXTENDED_PRECISION:
-      GSL_ERROR ("NetBSD only supports default precision rounding",
+      GSL_ERROR ("OpenBSD only supports default precision rounding",
                 GSL_EUNSUP);
       break;
     }

Toby

-- 
Toby White, University Chemical Lab., Lensfield Road, Cambridge. CB2 1EW. U.K.
Email: <tow@theor.ch.cam.ac.uk> GPG Key ID: 1DE9DE75
Web: <URL: http://ket.ch.cam.ac.uk/people/tow/index.html >
Tel: +44 1223 336423
Fax: +44 1223 336362

Re: gsl 0.8 compile error

[Brian Gough]

Toby White writes:
 > The patches below fix it - however, make check throws up a couple
 > of errors - I've addressed these in a separate post. This has 
 > only been tested on OpenBSD 2.9, but should work for any version
 > after 2.0.
 > 

Thanks. I have added that.  

Regarding the errors in complex I am suspicious of a few of them. In
particular,

FAIL: gsl_complex_arcsin imag part at (0.5,1.19209e-07) (1.37651030870007706e-07 observed vs 1.37651030824094312e-07 expected)

has a relative error of 3.33549e-10 but should be accurate to nearly
full precision (according to the paper of Hull et al).  If I run the
tests with GSL_IEEE_MODE=double-precision on x86 they pass ok, so they
should work on any machine with correct IEEE arithmetic.  Perhaps
there is an error in hypot() or log1p() on Openbsd??? (Does it use the
system functions or the ones in GSL?)

Brian

Re: gsl 0.8 compile error

[Toby White]

Brian Gough <bjg@network-theory.co.uk> writes:

> Toby White writes:
>  > The patches below fix it - however, make check throws up a couple
>  > of errors - I've addressed these in a separate post. This has 
>  > only been tested on OpenBSD 2.9, but should work for any version
>  > after 2.0.
>  > 
> 
> Thanks. I have added that.  
> 
> Regarding the errors in complex I am suspicious of a few of them. In
> particular,
> 
> FAIL: gsl_complex_arcsin imag part at (0.5,1.19209e-07) (1.37651030870007706e-07 observed vs 1.37651030824094312e-07 expected)
> 
> has a relative error of 3.33549e-10 but should be accurate to nearly
> full precision (according to the paper of Hull et al).  If I run the
> tests with GSL_IEEE_MODE=double-precision on x86 they pass ok, so they
> should work on any machine with correct IEEE arithmetic.  Perhaps
> there is an error in hypot() or log1p() on Openbsd??? (Does it use the
> system functions or the ones in GSL?)

Hmm. It uses the system functions by default. If I make it use gsl_log1p, then the only errors I get are:

FAIL: gsl_complex_arctanh real part at (1.19209e-07,0) (1.19209289550780125e-07 observed vs 1.19209289550781806e-07 expected)
FAIL: gsl_complex_arctanh real part at (-1.19209e-07,0) (-1.19209289550780125e-07 observed vs -1.19209289550781806e-07 expected)
FAIL: gsl_complex_arccoth real part at (1.19209e-07,0) (1.19209289550780125e-07 observed vs 1.19209289550781806e-07 expected)
FAIL: gsl_complex_arccoth real part at (-1.19209e-07,0) (-1.19209289550780125e-07 observed vs -1.19209289550781806e-07 expected)

and these remain even if I force it to use gsl_hypot and gsl_atanh.

The OpenBSD math functions are also lifted straight from NetBSD -
the source can be seen on the OpenBSD website (CVSweb - under
src/lib/libm/src) and by the look of the NetBSD source, is still
more or less identical. So NetBSD ought to suffer the same faults.
(The FreeBSD source seems to be substantially different; though
it claims to use the same method - a "Reme algorithm", apparently)

You are quite sure that the OpenBSD answer is the wrong one? I'm
happy to believe it, but it probably warrants some investigation, 
and a bug report to OpenBSD, if so.

Toby

-- 
Toby White, University Chemical Lab., Lensfield Road, Cambridge. CB2 1EW. U.K.
Email: <tow@theor.ch.cam.ac.uk> GPG Key ID: 1DE9DE75
Web: <URL: http://ket.ch.cam.ac.uk/people/tow/index.html >
Tel: +44 1223 336423
Fax: +44 1223 336362

Re: gsl 0.8 compile error

[Brian Gough]

Jason Beegan writes:
 >  For some NetBSD platforms there are two math libraries, the
 > portable C one, and an Assembly routine library.
 >  The C version passes all GSL tests on i386, but GSL fails the same
 > tests as on OpenBSD with the Assembly stuff. I only tested GSL with
 > the portable C version, so only after this discussion have I
 > noticed the problem.
 >  PS.  Now might be a good time to simplify fp-netbsd.c.  Please
 > apply this diff.

Thanks for the explanation. Patch applied. 

Re: gsl 0.8 compile error

[Jason Beegan]

I don't know about OpenBSD, but:

For some NetBSD platforms there are two math libraries, the portable C
one, and an Assembly routine library.

For i386 you have libm and libm387, and if /etc/ld.so.conf contains

libm.so.0	machdep.fpu_present	1:libm387.so.0,libm.so.0

then libm387 will be used in place of the C version.

Perhaps you need to remove a similar line from your ld.so.conf to
use the C version.

The C version passes all GSL tests on i386, but GSL fails the same
tests as on OpenBSD with the Assembly stuff. I only tested GSL with
the portable C version, so only after this discussion have I noticed
the problem.

I'll report it as a NetBSD bug.

Regards,

Jason Beegan


PS.  Now might be a good time to simplify fp-netbsd.c.  Please apply
this diff.


--- fp-netbsd.c~	Mon Jun 25 21:08:39 2001
+++ fp-netbsd.c	Mon Jun 25 21:10:27 2001
@@ -18,7 +18,6 @@
  */
 
 #include <ieeefp.h>
-#include <sys/param.h>
 #include <gsl/gsl_ieee_utils.h>
 #include <gsl/gsl_errno.h>
 
@@ -68,12 +67,13 @@
     }
 
 /* Turn on all available exceptions apart from 'inexact'.
-   Denormalized operand exception not available on all ports. */
+   Denormalized operand exception not available on all platforms. */
 
+  mode = FP_X_INV | FP_X_DZ | FP_X_OFL | FP_X_UFL;
 #ifdef FP_X_DNML
-  mode = FP_X_INV | FP_X_DNML | FP_X_DZ | FP_X_OFL | FP_X_UFL;
+  mode = mode | FP_X_DNML
 #else
-  mode = FP_X_INV | FP_X_DZ | FP_X_OFL | FP_X_UFL;
+
 #endif
 
   if (exception_mask & GSL_IEEE_MASK_INVALID)
@@ -83,7 +83,7 @@
 #ifdef FP_X_DNML
     mode &= ~ FP_X_DNML;
 #else
-  GSL_ERROR ("netbsd-" MACHINE " does not support the denormalized operand exception. "
+  GSL_ERROR ("NetBSD does not support the denormalized operand exception on this platform. "
 	     "Use 'mask-denormalized' to work around this.",
 	     GSL_EUNSUP);
 #endif

Re: gsl 0.8 compile error

[Toby White]

Jason Beegan <jtb@netbsd.org> writes:

> I don't know about OpenBSD, but:
> 
> For some NetBSD platforms there are two math libraries, the portable C
> one, and an Assembly routine library.
> 
> For i386 you have libm and libm387, and if /etc/ld.so.conf contains
> 
> libm.so.0	machdep.fpu_present	1:libm387.so.0,libm.so.0
> 
> then libm387 will be used in place of the C version.
> 
> Perhaps you need to remove a similar line from your ld.so.conf to
> use the C version.
> 
> The C version passes all GSL tests on i386, but GSL fails the same
> tests as on OpenBSD with the Assembly stuff. I only tested GSL with
> the portable C version, so only after this discussion have I noticed
> the problem.
> 
> I'll report it as a NetBSD bug.

Interesting. Although the OpenBSD source has the same division; into
a portable C version and an i386 assembler version; it looks like
only the assembler version gets built for i386. Certainly that's the
only version I can find on this system.

So if you want GSL to work properly under OpenBSD at the moment, you have 
to use gsl_log1p. A quick patch to configure.in is included below. I'll try
and come up with a better test that actually checks the output of log1p.

--- configure.in      Mon Jun 25 21:21:32 2001
+++ configure.in.new    Tue Jun 26 13:48:46 2001
@@ -61,7 +61,15 @@
 dnl Checks for library functions.
 AC_CHECK_LIB(m, main)
 AC_CHECK_FUNCS(hypot)
-AC_CHECK_FUNCS(log1p)
+dnl OpenBSD has a broken implementation of log1p.
+case "$host" in
+    *-*-*openbsd*)
+       AC_MSG_RESULT([Broken system log1p - using gsl version])
+       ;;
+    *)
+       AC_CHECK_FUNCS(log1p)
+       ;;
+esac
 AC_CHECK_FUNCS(expm1)
 AC_CHECK_FUNCS(acosh)
 AC_CHECK_FUNCS(asinh)

And on a separate note - there's a slight error in fp-openbsd.c
(and fp-netbsd.c) in CVS.

--- fp-openbsd.c.old  Tue Jun 26 11:35:11 2001
+++ fp-openbsd.c        Tue Jun 26 14:43:04 2001
@@ -74,7 +74,7 @@
 
   mode = FP_X_INV | FP_X_DZ | FP_X_OFL | FP_X_UFL;
 #ifdef FP_X_DNML
-  mode = mode | FP_X_DNML
+  mode = mode | FP_X_DNML;
 #endif
 
   if (exception_mask & GSL_IEEE_MASK_INVALID)


Toby

-- 
Toby White, University Chemical Lab., Lensfield Road, Cambridge. CB2 1EW. U.K.
Email: <tow@theor.ch.cam.ac.uk> GPG Key ID: 1DE9DE75
Web: <URL: http://ket.ch.cam.ac.uk/people/tow/index.html >
Tel: +44 1223 336423
Fax: +44 1223 336362

Re: gsl 0.8 compile error

[Brian Gough]

Toby White writes:
 > So if you want GSL to work properly under OpenBSD at the moment, you have 
 > to use gsl_log1p. A quick patch to configure.in is included below. I'll try
 > and come up with a better test that actually checks the output of log1p.

Thanks. An automatic test would be useful so that it adapts
automatically on future fixed versions.  It should be sufficient to
pick a few bad values of x and compare with the correct results I
would think.

Re: gsl 0.8 compile error

[Jason Beegan]

Sorry, there was a stray #else in the included diff.  Here is a fixed diff.


--- fp-netbsd.c~	Tue Jun 26 10:34:25 2001
+++ fp-netbsd.c	Tue Jun 26 10:32:07 2001
@@ -18,7 +18,6 @@
  */
 
 #include <ieeefp.h>
-#include <sys/param.h>
 #include <gsl/gsl_ieee_utils.h>
 #include <gsl/gsl_errno.h>
 
@@ -68,12 +67,11 @@
     }
 
 /* Turn on all available exceptions apart from 'inexact'.
-   Denormalized operand exception not available on all ports. */
+   Denormalized operand exception not available on all platforms. */
 
-#ifdef FP_X_DNML
-  mode = FP_X_INV | FP_X_DNML | FP_X_DZ | FP_X_OFL | FP_X_UFL;
-#else
   mode = FP_X_INV | FP_X_DZ | FP_X_OFL | FP_X_UFL;
+#ifdef FP_X_DNML
+  mode = mode | FP_X_DNML
 #endif
 
   if (exception_mask & GSL_IEEE_MASK_INVALID)
@@ -83,7 +81,7 @@
 #ifdef FP_X_DNML
     mode &= ~ FP_X_DNML;
 #else
-  GSL_ERROR ("netbsd-" MACHINE " does not support the denormalized operand exception. "
+  GSL_ERROR ("NetBSD does not support the denormalized operand exception on this platform. "
 	     "Use 'mask-denormalized' to work around this.",
 	     GSL_EUNSUP);
 #endif