unable to load shared object '/Library/Frameworks/R.framework/Versions/4.2/Resources/library/bnlearn/libs/bnlearn.so'

After the upgrade to R 4.2.2 and RStudio version 2022.12.0+353 (2022.12.0+353)
if I try to load the library(MRPC) or library(bnlearn) I receive the following error message:
Error: package or namespace load failed for ‘MRPC’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Library/Frameworks/R.framework/Versions/4.2/Resources/library/bnlearn/libs/bnlearn.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.2/Resources/library/bnlearn/libs/bnlearn.so, 0x0006): Library not loaded: /Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib
Referenced from: /Library/Frameworks/R.framework/Versions/4.2/Resources/library/bnlearn/libs/bnlearn.so
Reason: tried: '/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib' (no such file), '/Library/Frameworks/R.framework/Versions/4.1/Resources/lib/libRlapack.dylib' (no such file), '/usr/local/lib/libRlapack.dylib' (no such file), '/usr/lib/libRlapack.dylib' (no such file, not in .
With the previous Studio release all was fine.

This relates to LAPACK, a systems level library, rather than a specifically R one. It should have been installed with R 4.2.2. Why it wasn’t in the case of macOS depends on version and Intel vs. Silicon chip plus user#related decisions about installation specifics. For example brew and Anaconda don’t always play nicely with R and manually compiling works only if the system gods smile on the non-expert.

Share some detail?

Sorry, what I understand is that this error message happen after the update of Mac OS to Ventura 13.1 , R 4.2.2 ad the new version of RStudio Version 2022.12.0+353 (2022.12.0+353) downloaded from Posit location.
With the previous version of R and RStudio all was fine, probably there is some incongruence with the two new versions of R and RStudio

I have it working on Ventura, 4.2.2 and 353 on my M1. LAPACK is installed in a different location, under 4.2-arm64.

LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRlapack.dylib

Open a R console and report on configuration. Your R install hasn't updated as it should have.

sessionInfo()
#> R version 4.2.2 (2022-10-31)
#> Platform: aarch64-apple-darwin20 (64-bit)
#> Running under: macOS Ventura 13.1
#> 
#> Matrix products: default
#> BLAS:   /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib
#> LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/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] rstudioapi_0.14   knitr_1.41        magrittr_2.0.3    R.cache_0.16.0   
#>  [5] rlang_1.0.6       fastmap_1.1.0     stringr_1.5.0     styler_1.8.1     
#>  [9] highr_0.9         tools_4.2.2       xfun_0.35         R.oo_1.25.0      
#> [13] cli_3.4.1         withr_2.5.0       htmltools_0.5.4   yaml_2.3.6       
#> [17] digest_0.6.31     lifecycle_1.0.3   purrr_0.3.5       vctrs_0.5.1      
#> [21] R.utils_2.12.2    fs_1.5.2          glue_1.6.2        evaluate_0.19    
#> [25] rmarkdown_2.19    reprex_2.0.2      stringi_1.7.8     compiler_4.2.2   
#> [29] R.methodsS3_1.8.2

Getting a similar error message (running a model in rstan) after the update, for a script that ran perfectly on Friday:

Error in dyn.load(libLFile) :
unable to load shared object '/var/folders/ht/3542b6ss7hl9k3cyxz4nwtgh0000gn/T//Rtmp2LKyiw/filebfe33588b71d.so':
dlopen(/var/folders/ht/3542b6ss7hl9k3cyxz4nwtgh0000gn/T//Rtmp2LKyiw/filebfe33588b71d.so, 0x0006): Library not loaded: /Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libR.dylib
Referenced from: /private/var/folders/ht/3542b6ss7hl9k3cyxz4nwtgh0000gn/T/Rtmp2LKyiw/filebfe33588b71d.so
Reason: tried: '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libR.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libR.dylib' (no such file), '/Library/Frameworks/R.framework/Versions/4.1-arm64/Resources/lib/libR.dylib' (no such file), '/usr/local/lib/libR.dylib' (no such file), '/usr/lib/libR.dylib' (no such file, not in dyld cache)

@technocrat my sessionInfo() looks quite similar to yours:

> sessionInfo()
R version 4.2.2 (2022-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.1

Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/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 
[6] methods   base     

other attached packages:
 [1] rstan_2.21.7         StanHeaders_2.21.0-7
 [3] Matrix_1.5-1         forcats_0.5.2       
 [5] stringr_1.5.0        dplyr_1.0.10        
 [7] purrr_0.3.5          readr_2.1.3         
 [9] tidyr_1.2.1          tibble_3.1.8        
[11] ggplot2_3.4.0        tidyverse_1.3.2     
[13] foreign_0.8-83       data.table_1.14.6   
[15] sf_1.0-9            

loaded via a namespace (and not attached):
 [1] Rcpp_1.0.9          lattice_0.20-45    
 [3] lubridate_1.9.0     prettyunits_1.1.1  
 [5] class_7.3-20        ps_1.7.2           
 [7] assertthat_0.2.1    utf8_1.2.2         
 [9] R6_2.5.1            cellranger_1.1.0   
[11] backports_1.4.1     reprex_2.0.2       
[13] stats4_4.2.2        e1071_1.7-12       
[15] httr_1.4.4          pillar_1.8.1       
[17] rlang_1.0.6         readxl_1.4.1       
[19] googlesheets4_1.0.1 rstudioapi_0.14    
[21] callr_3.7.3         googledrive_2.0.0  
[23] loo_2.5.1           munsell_0.5.0      
[25] proxy_0.4-27        broom_1.0.2        
[27] compiler_4.2.2      modelr_0.1.10      
[29] pkgconfig_2.0.3     pkgbuild_1.4.0     
[31] tidyselect_1.2.0    gridExtra_2.3      
[33] codetools_0.2-18    matrixStats_0.63.0 
[35] fansi_1.0.3         withr_2.5.0        
[37] tzdb_0.3.0          crayon_1.5.2       
[39] dbplyr_2.2.1        grid_4.2.2         
[41] jsonlite_1.8.4      gtable_0.3.1       
[43] lifecycle_1.0.3     DBI_1.1.3          
[45] magrittr_2.0.3      units_0.8-1        
[47] scales_1.2.1        RcppParallel_5.1.5 
[49] KernSmooth_2.23-20  stringi_1.7.8      
[51] cli_3.4.1           fs_1.5.2           
[53] xml2_1.3.3          ellipsis_0.3.2     
[55] generics_0.1.3      vctrs_0.5.1        
[57] tools_4.2.2         glue_1.6.2         
[59] hms_1.1.2           processx_3.8.0     
[61] parallel_4.2.2      timechange_0.1.1   
[63] inline_0.3.19       colorspace_2.0-3   
[65] gargle_1.2.1        rvest_1.0.3        
[67] classInt_0.4-8      haven_2.5.1 

I'm noticing that that in both my case and the previously reported issue, R is searching for the libR.dylib in /Versions/4.1-arm64 instead of /Versions/4.2-arm64- isn't that a problem?

But not this one, also?

The BLAS is missing indeed-do you know what it corresponds to? I will investigate currently.

This is discussed in §10.5 of the R for macOS FAQ on CRAN. Unfortunately, the way the site operates I cannot provide a direct link.

Quoting:

10.5 Which BLAS is used and how can it be changed?

The BLAS library used by R depends on the way R was compiled (see ‘R Installation and Administration’ manual for details). Current R binaries supplied from CRAN provide both vecLib-based BLAS and reference BLAS shipped with R. vecLib is a part of Apple’s Accelerate framework which provides an optimized BLAS implementation for Mac hardware. Although fast, it is not under our control and may possibly deliver inaccurate results.

The CRAN binary uses --enable-BLAS-shlib option and two Rblas shared libraries are supplied: libRblas.vecLib.dylib which uses vecLib BLAS and libRblas.0.dylib which uses reference BLAS from R. A symbolic link libRblas.dylib determines which one is used. Currently the default is to use the R BLAS: this is recommended for precision.

In order to change which BLAS is used, change the libRblas.dylib symlink correspondingly – for example in Terminal:

cd /Library/Frameworks/R.framework/Resources/lib # for vecLib use ln -sf libRblas.vecLib.dylib libRblas.dylib # for R reference BLAS use ln -sf libRblas.0.dylib libRblas.dylib

This feature is only present in the R CRAN binary. Ordinarily compiled R from sources will only have one of the above BLAS libraries, corresponding to the configuration options used.

The BLAS library used is displayed in sessionInfo().

Doing this doesn't require advanced sysadm skills, but a beginner should probably seek in-person assistance from someone who understands file permissions and symbolic links. Or you can try a re-installation. Be sure to use the pkg and not attempting to compile from source. Also be sure to use the installer appropriate for your processor—Silicon vs Intel.

I realize that the BLAS library is displayed when I use R rather than RStudio:

sessionInfo()
R version 4.2.2 (2022-10-31)
Platform: aarch64-apple-darwin20 (64-bit)
Running under: macOS Ventura 13.1

Matrix products: default
BLAS: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/lib/libRblas.0.dylib
LAPACK: /Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/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.2.2

So maybe the problem stems from my installation of RStudio. Or as you mentioned above, having RStudio pointing at the wrong version of the BLAS library.

Details are different, but this sounds much like the problem I asked about earlier today.

For some reason the glue.so seems to be pointing to the wrong directory.

1 Like

Definitely looks like a $PATH problem with RStudio looking for love in all the wrong places. You can check with

.libPaths()
#> [1] "/Library/Frameworks/R.framework/Versions/4.2-arm64/Resources/library"

and if it points to a library under your user, you can use .libPaths(...) at the top of a script to fix temporarily while continuing to troubleshoot.

1 Like

This topic was automatically closed 42 days after the last reply. New replies are no longer allowed.

If you have a query related to it or one of the replies, start a new topic and refer back with a link.