On 15 Jan 2026, at 06:05, Myles Lewis via R-SIG-Mac <r-sig-mac at r-project.org> wrote:
I wanted to report an issue with R 4.5.2 for arm64, which is caused by the change in the default BLAS from R?s standard BLAS library to using Apple Accelerate vecLib BLAS library by default. In 4.5.1 and earlier, R for macOS ships with the standard R BLAS. To change to vecLib, users had to deliberately invoke this using a terminal command to change a symlink:
https://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html#Which-BLAS-is-used-and-how-can-it-be-changed_003f
However, R 4.5.2 for arm64 now defaults to vecLib. For intel macOS, 4.5.2 stays with the standard R BLAS. VecLib BLAS has a problem with parallelisation using mclapply() which now gives a warning and returns NULL if mc.cores >= 2 and vecLib is invoked e.g. by the use of crossprod(). Here?s a short reprex:
system("readlink /Library/Frameworks/R.framework/Resources/lib/libRblas.dylib")
# R 4.5.2 arm64: libRblas.vecLib.dylib
# R 4.5.1 arm64: libRblas.0.dylib
N <- 200
M <- 4000
X <- matrix(rnorm(N*M),N)
library(parallel)
# ok
res <- mclapply(1:4, function(i) {crossprod(X + i)}, mc.cores = 1)
# ok in R 4.5.1
# not ok in R 4.5.2 arm64 (but works if M is smaller)
res <- mclapply(1:4, function(i) {crossprod(X + i)}, mc.cores = 2)
# gives warning and `res` contains NULL
The same error occurs on Intel & arm Macs with any version of R if the BLAS is switched to VecLib by symlink.
My question is whether R for arm64 should go back to standard R BLAS by default. Otherwise, users may find that functions which invoke the BLAS e.g. lm() may crash unexpectedly and return NULL when parallelised using mclapply (a fairly common situation in lots of packages).
Thanks,
Myles Lewis
[[alternative HTML version deleted]]