[R-SIG-Mac] CRAN package checks on M1 Mac

[Taras Zakharko]

Thanks, this is great!

Why do you say that OpenGL is not available though? M1 has a fully working OpenGL framework implemented on top of Metal. Apple might have deprecated OpenGL, but I think it’s unlikely they will drop it any time soon seeing that they went through the effort of updating their OpenGL wrapper to support desktop GL. 

Best, 

Taras


> On 21 Dec 2020, at 17:32, Duncan Murdoch <murdoch.duncan using gmail.com> wrote:
> 
> Along the same lines:  I have been working with Prof Ripley to get rgl to work on M1.  Since OpenGL isn't available, it produces only WebGL output (viewable using rglwidget()) and can't do snapshots or Postscript output, but it should be enough to let its reverse dependencies install.
> 
> Anyone interested in testing it can install from R-forge or Github:
> 
> install.packages("rgl", repos="http://R-Forge.R-project.org", type = "source")
> 
> or
> 
> remotes::install_github("https://github.com/r-forge/rgl", subdir = "pkg/rgl")
> 
> To see what it looks like without OpenGL on Windows, try
> 
> Sys.setenv(RGL_NO_OPENGL = TRUE)
> 
> before the install, or on a Unix-alike,
> 
> install.packages("rgl", repos="http://R-Forge.R-project.org",
>                  INSTALL_opts = '--configure-args="--disable-opengl"',
>                  type = "source")
> 
> Duncan Murdoch
> 
> 
> On 21/12/2020 9:01 a.m., Jeroen Ooms wrote:
>> On Sun, Dec 13, 2020 at 6:45 AM Prof Brian Ripley <ripley using stats.ox.ac.uk> wrote:
>>> 
>>> We have managed a fairly complete check run with natively-compiled R and
>>> packages, and a full one with x86_64 R and packages running under
>>> Rosetta (mainly using CRAN binary distributions).
>>> 
>>> The bottom line is that running under Rosetta works really well.
>>> Although relative speeds vary widely, using the native build was
>>> 1.3-1.5x faster for the central 50% of the distribution.  And a MacBook
>>> Air is remarkably capable for a lightweight laptop.
>>> 
>>> 
>>> x86_64 tests
>>> ------------
>>> 
>>> I compared the check output to that from my 2012 iMac: typically this
>>> was 1.7x faster than the iMac (and benchmarks have current iMac/MacMini
>>> about that much faster than mine).
>>> 
>>> A couple of packages ran much slower than on the iMac and hit their
>>> check limits, and one fails because it checks elapsed time (and was
>>> slower than on the iMac).
>>> 
>>> 10 packages segfaulted in their checks (but most of those are known to
>>> segfault intermittently on other platforms).
>>> 
>>> There were issues with packages attempting to work with Python, which
>>> may be Big Sur differences.
>>> 
>>> Given that I have 58 packages failing their checks on the iMac under
>>> High Sierra this was a very small amount of degradation.
>>> 
>>> 
>>> native tests
>>> ------------
>>> 
>>> Currently I have 57 CRAN packages failing to install, but 650 others
>>> require those or BioC packages which fail to install (the most commonly
>>> required being rgl and V8 [*]).  And ca 120 packages are not using
>>> conditionally Suggests packages which fail to install.
>>> 
>>> There are segfaults from ca 150 packages using minpack.lm::nls.lm,
>>> deSolve::lsoda, rootSolve::stode ... all of which use Fortran.
>>> 
>>> That platform does not have long doubles nor extended precision but the
>>> CRAN checking on Linux and Sparc with --disable-long-doubles has paid
>>> off: only a handful of check results show numerical differences.
>>> 
>>> Quite a lot of external software and several packages have had to be
>>> patched, and it is early days for the former (and the Fortran compiler)
>>> - for example I was able to build v8, but V8 segfaulted in its checks.
>> Thank you for these fantastic efforts. I have added a binary for
>> libv8, so it works on arm64 now.
>> Re: the more general problem of external software, are there any
>> details available on how the external software on your server was
>> built/configured? For example I don't see libv8 on
>> https://github.com/R-macos/recipes or
>> https://mac.r-project.org/libs-arm/ so this makes it difficult for
>> package authors to debug a problem.
>> FWIW, Homebrew is quickly catching up on M1 support. Many people are
>> contributing patches, and François-Xavier Coudert (the same person who
>> is publishing the gfortran binaries) is publishing the homebrew arm64
>> binaries (aka bottles), hundreds over the past weekend:
>> https://github.com/Homebrew/homebrew-core/commits?author=fxcoudert
>> It is recommended to install homebrew on ARM in /opt/homebrew, and not
>> /usr/local, to prevent binaries from getting mixed up
>> (https://github.com/mikelxc/Workarounds-for-ARM-mac ). Using these
>> standard instructions, I was able to check many R packages that are
>> flagged on CRAN. For example:
>>     brew install --build-from-source libgit2
>> Will make it possible to install gert and git2r. And:
>>     brew install --build-from-source imagemagick using 6
>> Will work for 'magick' and:
>>     brew install protobuf
>> For protolite.
>> The main bottlenecks are libraries that depend (indirectly) on gcc
>> (fortran) or rust. FXCoudert is working on gcc, and for Rust, support
>> for apple-arm is available starting rust 1.49, which will be released
>> on Jan 1.
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac using r-project.org
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>> 
> 
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac using r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac