From prye at shiraz.apana.org.au  Wed Jul 30 15:28:11 2003
From: prye at shiraz.apana.org.au (Peter Rye)
Date: Wed Jul 30 16:28:12 2003
Subject: [Rd] OpenBSD-alpha and R-1.7.1 problem
In-Reply-To: <Pine.LNX.4.44.0307301023390.15604-100000@gannet.stats>
References: <Pine.LNX.4.44.0307301023390.15604-100000@gannet.stats>
Message-ID: <87brvc8841.fsf@riesling.grape.apana.org.au>

>>>>> "Prof Ripley" == Prof Brian Ripley <ripley@stats.ox.ac.uk> writes:

    Prof Ripley> On 29 Jul 2003, Peter Rye wrote:
    >> I'm trying to get R running on OpenBSD/alpha.
    >> 
    >> I've applied some configure patches which I've previously sent to
    >> the R-devel list to allow R to compile on an OpenBSD ELF platform
    >> (which OpenBSD/alpha is, as the i386 port soon will be).
    >> 
    >> The patched source compiles without problems, and appears to run and
    >> perform properly apart from two (possibly unrelated) problems.
    >> 
    >> 1) On startup there are complaints about mismatched symbol sizes
    >> (see below). This error message comes from the OpenBSD ld.so, and
    >> doesn't occur on OpenBSD/i386.
    >> 
    >> On further investigation this seems to occur when the modreg and ts
    >> packages are loaded together. In both packages, the R_*MethodDef
    >> arrays are declared globally rather than "static const". Changing
    >> these declarations to static const results in the warning
    >> disappearing. I think this is *probably* a correct fix. Am I missing
    >> something or am I talking/writing garbage. The patch is
    >> straightforward, I can send it to one of you if you wish - then
    >> again perhaps it's not the right fix.

    Prof Ripley> It's OK for those arrays to be static, and I am adding
    Prof Ripley> that to places where they are not (modreg, tools, ts)

Excellent. Further testing here seems to indicate that this is the cause of
the warning on OpenBSD/alpha. These arrays presumably don't necessarily
need to be "const" - correct?


Further to my last post on OpenBSD/alpha.
The FP exceptions and core dumps have remained a problem.
I thought I'd found an obvious "fix", but unfortunately it didn't solve the
problem. I tried applying the patch below which looks "right" but the
fpsetmask() on OpenBSD doesn't do what I thought it should - no doubt a
lack of understanding on my part.

I was however able to get R-devel and R-1.7.1 running eventually with a
rather ugly brute force technique of recompiling a math library for R's
use, using the -mieee flag in the library build. 

This *actually *works** (or appears to in limited testing). Presumably that's
why I couldn't track down the SIGFPE on debugging of R - it may be occuring
the the math library.

It _might_ be an OpenBSD specific problem. Anyone have any experience with
Net or FreeBSD/alpha and R which can shed some further light on this?

Regards,
Peter Rye


<code>

--- src/unix/sys-unix.c.orig    Wed Jul 30 12:12:22 2003
+++ src/unix/sys-unix.c Wed Jul 30 12:55:05 2003
@@ -370,6 +370,15 @@
 # endif
 #endif

+#if defined (__OpenBSD__) || defined (__NetBSD__)
+/*
+I believe Net/OpenBSD uses the same header and system call
+Tested for in configure in R-devel #ifdef HAVE_IEEEFP_H
+*/
+#include <ieeefp.h>
+#endif
+/*                                 #endif */
+
 #ifdef linux
 # ifdef HAVE_FPU_CONTROL_H
 #  include <fpu_control.h>
@@ -379,7 +388,7 @@
 void fpu_setup(Rboolean start)
 {
     if (start) {
-#ifdef __FreeBSD__
+#if defined (__FreeBSD__) || defined (__NetBSD__) || defined (__OpenBSD__)
     fpsetmask(0);
 #endif

@@ -387,7 +396,7 @@
     __setfpucw(_FPU_IEEE);
 #endif
     } else {
-#ifdef __FreeBSD__
+#if defined (__FreeBSD__) || defined (__NetBSD__) || defined (__OpenBSD__)
     fpsetmask(~0);
 #endif

</code>


[Rd] OpenBSD-alpha and R-1.7.1 problem
Peter Rye