Skip to content

Installing CRAN binary packages with R 4.0 installed from source crashes R

8 messages · Simon Urbanek, Hervé Pagès, Brian Ripley

#
Hi Simon,

After installing R 4.0 alpha from source on a macOS Mojave system, R 
won't let me use type="both" to install CRAN packages. I get:

   Error in install.packages("rJava", type = "both", repos = 
"https://cran.r-project.org") :
     type == "both" can only be used on Windows or a CRAN build for macOS

OK so this suggests that the CRAN binary packages for R 4.0 are not 
compatible with my R. Surprisingly though using type="mac.binary" 
doesn't complain and lets me install these binaries. But then trying to 
load them causes segfaults. I've tried this with rJava, Rcpp, ggplot2, 
and doing library() on any of them crashes my session. Note that 
installing all these packages from source works without any problem.

So my questions are: is it the case that CRAN binary packages are not 
meant to be used with an R 4.0 installed from source? If yes then why 
isn't type="mac.binary" blocking this like type="both" does?

Thanks,
H.

 > sessionInfo()
R version 4.0.0 alpha (2020-04-01 r78132)
Platform: x86_64-apple-darwin18.7.0 (64-bit)
Running under: macOS Mojave 10.14.6

Matrix products: default
BLAS:   /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

loaded via a namespace (and not attached):
[1] compiler_4.0.0
#
Herv?,

"both" is a fairly recent addition and my guess would be that it has been guarded specifically since it is the default and installing binaries only works for the CRAN version. I didn't look at the new "both" code to see how it knows that it's the CRAN version - there is really no special "CRAN" flag. At some point we were guarding binary installs in general by checking the OS and R, but it was fragile - you could be building using the same system as we do and yet use a different compiler, so I think it's in general impossible unless we introduce some extra identification of the binaries. So, yes, if you compile R from sources yourself it is not guaranteed to be compatible with CRAN package binaries. Those are only built and tested with the CRAN R binary.

Cheers,
Simon
#
FWIW I also get the same thing (i.e. R crashes on loading CRAN binary 
packages) if I configure R 4.0 alpha like here 
https://svn.r-project.org/R-dev-web/trunk/QA/Simon/R4/conf.high-sierra-x86_64, 
that is, if all the compilers use -mmacosx-version-min=10.13 and I set 
--build=x86_64-apple-darwin17.0

In that case I end up with the following sessionInfo():

   > sessionInfo()
   R version 4.0.0 alpha (2020-04-01 r78132)
   Platform: x86_64-apple-darwin17.0 (64-bit)
   Running under: macOS Mojave 10.14.6

   Matrix products: default
   BLAS:   /Users/biocbuild/bbs-3.11-bioc/R/lib/libRblas.dylib
   LAPACK: /Users/biocbuild/bbs-3.11-bioc/R/lib/libRlapack.dylib

   locale:
   [1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

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

   loaded via a namespace (and not attached):
   [1] compiler_4.0.0

H.
On 4/1/20 23:47, Herv? Pag?s wrote:

  
    
#
Thanks. Only seeing this after I sent my other email about also getting 
crashes when I use your conf.high-sierra-x86_64 settings. But of course 
I'm not on Catalina so my setting is not exactly the same as yours. 
Therefore I should conclude that the CRAN binaries are not meant for me.

H.
On 4/2/20 01:34, Simon Urbanek wrote:

  
    
#
On 02/04/2020 09:34, Simon Urbanek wrote:
It is simple: type = 'both' has to know what the two types are.  Only 
the CRAN binaries have the default type set to "mac.binary": building 
from the sources gives you a default type of "source".  See ?.Platform.

  
    
#
On 4/2/20 02:05, Prof Brian Ripley wrote:
AFAIK the CRAN binary has the default type set to "both".

Anyway knowing the defaults is interesting but only orthogonal to the 
discussion.

H.

  
    
#
Herv?,

what Brian was referring to was
[1] "mac.binary"

Cheers,
Simon
#
Yeah I **guess** so. Even though a close look at ?.Platform doesn't 
particularly help clarify the somewhat fuzzy concept of "default type" 
or "preferred setting for options('pkgType')":

    pkgType: character string, the preferred setting for
             ?options("pkgType")?.  Values ?"source"?,
             ?"mac.binary.el-capitan"? and ?"win.binary"? are
             currently in use.

   > options("pkgType")
   $pkgType
   [1] "both"

Cheers,
H.
On 4/2/20 13:34, Simon Urbanek wrote: