[Rd] R-1.7.0 build feedback: NetBSD 1.6 (PR#2837)

[Prof Brian Ripley]

On Sun, 4 May 2003, Kurt Hornik wrote:

> >>>>> Prof Brian Ripley writes:
> 
> > On Sat, 3 May 2003 beebe at math.utah.edu wrote:
> >> This is a followup to my report of a SIGSEGV in R-1.7.0 built
> >> on NetBSD 1.6.
> >> 
> >> Kurt Hornik responded:
> >> 
> >> >> ...
> >> >> After some discussions on r-core, two suggestions.
> >> >>
> >> >> * It might be helpful to know if zlib has found in the OS or compiled
> >> >>   from the sources within R: if the first you could try configure
> >> >>   --without-zlib as it is possible the OS has a modified version.
> >> >>
> >> >> * You have
> >> >>
> >> >>   R : Copyright 2003, The R Development Core Team
> >> >>   Version 1.7.0 Under development (unstable) (2003-04-11)
> >> >>                       ^^^^^^^^^^^^^^^^^^^^^^         ^^^
> >> >>
> >> >>   and might just have hit a bad day of the r-devel daily snapshot.
> >> >> ...
> >> 
> >> I don't think that the latter is the problem.  This version built,
> >> validated, and installed on several other platforms.
> >> 
> >> Since my initial bug report for this system, I upgraded the gcc
> >> release from 3.2.2 to the latest 3.2.3, so the compilation environment
> >> is now a bit different.
> >> 
> >> I tried your suggestion of the --without-zlib configure option, and
> >> that produced a working R, which I've installed.  There was one *.fail
> >> file in the tests directory: reg-tests-1.Rout.fail.  It is 2280 lines
> >> long, and contains a fair number of "Error xxx" reports.
> 
> > About 12 are expected.  The error will be in the last command line, so 
> > only the last few lines of the file are relevant: to wit
> 
> >> ## pweibull(large, log=T):
> >> stopifnot(pweibull(seq(1,50,len=1001), 2,3, log = TRUE) < 0)
> > Error: pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) < 0 is not TRUE
> 
> > for which you would need to investigate the output of
> 
> > pweibull(seq(1, 50, len = 1001), 2, 3, log = TRUE) 
> 
> > and I guess that this is an accuracy problem in the runtime (libc).
> 
> So the conclusion would be that the system's -lz is broken?  Argh ...

Most likely, yes.  I've floated the idea before of not using a system -lz
as an insurance (and am intending to look for 1.1.4, not just 1.1.3, in 
1.8.0 once I get around to untangling the two uses of -lz in configure).

Brian

-- 
Brian D. Ripley,                  ripley at stats.ox.ac.uk
Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
University of Oxford,             Tel:  +44 1865 272861 (self)
1 South Parks Road,                     +44 1865 272866 (PA)
Oxford OX1 3TG, UK                Fax:  +44 1865 272595