Skip to content

64-bit R-build on Mac OS X 10.4 - make check failures

3 messages · Steven McKinney, Brian Ripley, Simon Urbanek

#
Hi all,

I compiled 64-bit R on an Apple Mac G5 running OS X, but it failed 
make check.  Simon Urbanek suggested I post results to R-devel.
Many thanks to Simon Urbanek for providing a 64-bit libiconv for
use on the Apple Mac OS X platform.  This allowed compilation
on the Mac without having to use the '--without-iconv' switch
(for those of us who are not yet proficient at compiling 64-bit
libraries on the Mac).

Compilation of 64-bit R succeeded, but make check did not.

First failure was in ok-errors.R, and generated this output
in ok-errors.Rout.fail

   > ## bad infinite recursion / on.exit / ... interactions
   > bar <- function() 1+1
   > foo <- function() { on.exit(bar()); foo() }
   > foo() # now simple "infinite recursion"
   
    *** caught segfault ***
   address 0x7fffeff7ffe30, cause 'memory not mapped'
   
   Traceback:
    1: foo()
    2: foo()
    3: foo()
   ...
   2154: foo()
   2155: foo()
   2156: foo()
   aborting ...

Second error was in d-p-q-r-tests.Rout from this test:
   ## dbeta(*, ncp):
   a <- rlnorm(100)
   stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
             dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
             )
   ## the first gave 0, the 2nd NaN in R <= 2.3.0

and generated this
output in d-p-q-r-tests.Rout.fail

   > 
   > ## dbeta(*, ncp):
   > a <- rlnorm(100)
   > stopifnot(All.eq(a, dbeta(0, 1, a, ncp=0)),
   +           dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf
   +           )
   Error: dbeta(0, 0.9, 2.2, ncp = c(0, a)) == Inf is not all TRUE
   In addition: Warning message:
   In dnbeta(x, shape1, shape2, ncp, log) : NaNs produced
   Execution halted

Everything else passed, so I'm not sure how serious these failures are.

I'd appreciate any suggestions about how to figure out what caused these 
failures (an inappropriate file somewhere in the path, a possible
bug, improper compilation commands etc.) 


version information of compiled R (compilation information at end):
R version 2.6.0 Patched (2007-10-29 r43302) 
powerpc64-apple-darwin8.10.0 

locale:
C

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] lme4_0.99875-8    Matrix_0.999375-3 lattice_0.17-2   

loaded via a namespace (and not attached):
[1] grid_2.6.0      rcompgen_0.1-17
$platform
[1] "powerpc64-apple-darwin8.10.0"

$arch
[1] "powerpc64"

$os
[1] "darwin8.10.0"

$system
[1] "powerpc64, darwin8.10.0"

$status
[1] "Patched"

$major
[1] "2"

$minor
[1] "6.0"

$year
[1] "2007"

$month
[1] "10"

$day
[1] "29"

$`svn rev`
[1] "43302"

$language
[1] "R"

$version.string
[1] "R version 2.6.0 Patched (2007-10-29 r43302)"
$OS.type
[1] "unix"

$file.sep
[1] "/"

$dynlib.ext
[1] ".so"

$GUI
[1] "X11"

$endian
[1] "big"

$pkgType
[1] "source"

$path.sep
[1] ":"

$r_arch
[1] ""
I built 64-bit R on Mac OS X 10.4.10 with these commands:

export PATH='/usr/local/lib64/X11/bin:/usr/local/lib64/X11/etc:/usr/local/lib64/X11/include:/usr/local/lib64/X11/lib:/usr/lib:/usr/bin:/usr/local/sbin:/usr/local/bin:/bin:/usr/sbin:/sbin:/usr/local/teTeX/bin/powerpc-apple-darwin-current:~/perl:~/bin'

./configure --host=powerpc64-apple-darwin8.10.0 --build=powerpc64-apple-darwin8.10.0 \
--prefix=/usr/local/lib64 'CC=gcc-4.0 -arch ppc64' 'CXX=g++ -arch ppc64' \
'FC=gfortran-4.0 -arch ppc64' 'F77=gfortran-4.0 -arch ppc64' \
'CFLAGS=-g -O3 -mtune=G5 -mcpu=G5' 'FFLAGS=-g -O3 -mtune=G5 -mcpu=G5' \
'LDFLAGS=-arch ppc64 -m64 -L/usr/local/lib' 'CXXFLAGS=-g -O3 -mtune=G5 -mcpu=G5' \
'FCFLAGS=-g -O3 -mtune=G5 -mcpu=G5' --disable-R-framework --enable-R-shlib \
'--with-blas=-framework vecLib' --with-lapack 1> configure.R.ppc64.out.20071107.Run01.txt 2>&1

sudo make 1> make.R.ppc64.out.20071107.Run01.txt  2>&1

sudo make check 1> make.check.R.ppc64.out.20071107.Run01.txt  2>&1




Steve McKinney
#
I am not sure why Simon thought you should ask here (and not on R-sig-mac, 
say): it is almost certain these are problems with your system not R. 
For the first, use your debugger to find where the segfault occurred (it 
might be inadequate stack space).  For the second, look at the values of 
dbeta(0, 0.9, 2.2, ncp = c(0, a)), and trace the C code to find out why 
you are not getting Inf (it is probably a broken libm function).

I'd be worried about the first: the second is probably esoteric.
On Wed, 7 Nov 2007, Steven McKinney wrote:

            

  
    
#
On Nov 8, 2007, at 2:22 AM, Prof Brian Ripley wrote:

            
mainly because of the d-p-q-r-test - I was wondering whether it falls  
in the category of too strict tests or is a more serious issue. I  
can't look into it myself right now, so I was hoping someone might  
have an idea ...

Thanks,
Simon