positron
positron copied to clipboard
posit-dev
package or namespace load failed for ‘dplyr’ in dyn.load
Hello, thanks for this new IDE. I was expecting this for so long time. First try here on macOS Sonoma 14.3.1. Intel (macBookPro)
I am using vscode for 1 year now and everything run smootlhy. After Positron install, I try to load some libraries but it fails. I checked the R version and .libPaths and both IDE have the same values.
Here the error message :
What can I do?
I received the same error message when I try to load the "tydverse" library:
library(tidyverse) Error: ! package or namespace load failed for ‘tidyverse’ in dyn.load(file, DLLpath = DLLpath, ...): no es posible cargar el objeto compartido '/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so': dlopen(/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so, 0x0006): Library not loaded: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib Referenced from: <270B8E9B-4B07-38A5-8F07-D40F024B1184> /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so Reason: tried: '/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib' (no such file), '/Library/Frameworks/R.framework/Versions/4.3-x86_64/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) Hide Traceback ▆
- └─base::library(tidyverse)
- └─base::tryCatch(...)
-
└─base (local) tryCatchList(expr, classes, parentenv, handlers) -
└─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]]) -
└─value[[3L]](cond)
It looks like some macOS distributions of R packages do not link to R with an absolute path and we'll need to reintroduce DYLD_FALLBACK_LIBRARY_PATH which we removed in https://github.com/posit-dev/positron/pull/2083. I.e. we'll need the same fix as for Linux: https://github.com/posit-dev/positron/pull/2809.
We'll have to do the same in Ark's kernel spec and make sure generated binaries are signed with appropriate entitlements.
To confirm this @dsolito and @JulianRamajo, could you please run otool -L path/to/pkg-lib.so in the terminal and give us the output? For instance in Julian's case it would be:
otool -L /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so
First of all, thank you for the quick response. Below are the requested data. I'm using Positron on macOS Ventura 13.6.7. Intel (MacBook Pro).
MacBook-Pro-de-Julian:~ julian_ramajo$ otool -L /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so
/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/magrittr/libs/magrittr.so:
magrittr.so (compatibility version 0.0.0, current version 0.0.0)
/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib (compatibility version 4.3.0, current version 4.3.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1775.118.101)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.100.5)
Thank you for your message @lionel- Please find the result of the query :
otool -L /usr/local/lib/R/4.3/site-library/magrittr/libs/magrittr.so
/usr/local/lib/R/4.3/site-library/magrittr/libs/magrittr.so:
magrittr.so (compatibility version 0.0.0, current version 0.0.0)
/usr/local/opt/r/lib/R/lib/libR.dylib (compatibility version 4.3.0, current version 4.3.2)
/usr/local/opt/gettext/lib/libintl.8.dylib (compatibility version 13.0.0, current version 13.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
Thank you both!
@JulianRamajo magrittr is compiled for R 4.3 even though it's located in the R 4.4 folder. Did you copy it there after upgrading R? Or did you manually install a package bundle compiled for this older R version?
I assume that it works outside of Ark but even so there's no guarantee that this should work. It's recommended to update all packages after updating to a new major or minor version of R because binary compatibility is only guaranteed across patch releases.
@dsolito Do you know what kind of R used to be installed in /usr/local/opt/r/lib/R/lib/libR.dylib?
Relatedly, with a dev version o R compiled locally I get:
[R] 2024-07-07T08:33:42.924408Z ERROR Panic! In file 'crates/harp/src/library.rs' at line 23: The R shared library at '/usr/local/lib/R/lib/libR.dylib' could not be opened: DlOpen { desc: "dlopen(/usr/local/lib/R/lib/libR.dylib, 0x0009): Library not loaded: libRblas.dylib\n Referenced from: <5FADC182-EBBD-3E2B-9544-B5FE7D3FB7FC> /usr/local/lib/R/lib/libR.dylib\n Reason: tried: \'libRblas.dylib\' (no such file), \'/System/Volumes/Preboot/Cryptexes/OSlibRblas.dylib\' (no such file), \'libRblas.dylib\' (no such file), \'/Users/lionel/Sync/Projects/R/tidyverse/dplyr/libRblas.dylib\' (no such file), \'/System/Volumes/Preboot/Cryptexes/OS/Users/lionel/Sync/Projects/R/tidyverse/dplyr/libRblas.dylib\' (no such file), \'/Users/lionel/Sync/Projects/R/tidyverse/dplyr/libRblas.dylib\' (no such file)" }
In this case the libR library is linked against its internal deps (e.g. libRblas) with relative paths. This should also be solved by setting DYLD_LIBRARY_PATH.
@dsolito Do you know what kind of R used to be installed in /usr/local/opt/r/lib/R/lib/libR.dylib?
I had previously installed R from brew, but I had too many problems. So I went back to the CRAN version.
This is exactly the method I follow when I upgrade the R version: I copy the contents of the "library" folder from the old one to the new version, except the folders of the new R version. Is there a more appropriate method of updating all libraries when upgrading an R version? In any case, this morning I did a rebuild of all the R libraries in R version 4.4.1 [ renv::rebuild(recursive = TRUE) ] and I got the same error message when I try to use any library in the R console of Positron.
This is exactly the method I follow when I upgrade the R version: I copy the contents of the "library" folder from the old one to the new version, except the folders of the new R version. Is there a more appropriate method of updating all libraries when upgrading an R version?
In general, if you want to update your version of R, you should also be prepared to update your R packages to the latest versions available. There's no guarantee that older versions of packages will work with newer releases of R, especially with a new major / minor release.
If you do want to try and preserve the same versions from before, you can do something like this from your "older" R installation (assuming renv):
renv::snapshot(type = "all")
And then later (from your "new" R installation)
renv::restore()
@dsolito @JulianRamajo I have just committed a fix for this. Could you please try the next released version of positron (the current one, 2024.07.0-107, doesn't have the fix yet) and see if that fixes things for you?
Hi @lionel- Of course, I will. How can I test the next release ? I see the 2024.07.0-107 only.
Here it is! 🤞 https://github.com/posit-dev/positron/releases/tag/2024.07.0-113
Thank you. Same problem than before
> library(tidyr)
Error:
! package or namespace load failed for ‘tidyr’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/usr/local/lib/R/4.3/site-library/vctrs/libs/vctrs.so':
dlopen(/usr/local/lib/R/4.3/site-library/vctrs/libs/vctrs.so, 0x0006): Library not loaded: /usr/local/opt/r/lib/R/lib/libR.dylib
Referenced from: <154F145B-B922-329E-87C6-A8757684CDB0> /usr/local/lib/R/4.3/site-library/vctrs/libs/vctrs.so
Reason: tried: '/usr/local/opt/r/lib/R/lib/libR.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/r/lib/R/lib/libR.dylib' (no such file), '/usr/local/opt/r/lib/R/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)
Show Traceback
Strange. I tried it locally (inject in my library a vctrs.so compiled for a different version of R with an absolute path to a missing libR.dyld) and it does work for me with the newest version of positron. Whereas an older version produces the same error as you're seeing.
Maybe we should wait for more feedback from other users? In the meantime I'd recommend fixing your library (reinstalling all your packages so that they are linked against the correct version of R, it's best to start from scratch with an empty package library). This should unblock you and is the safer course of action in any case.
Ok. Thanks. Just to let you know. I took the decision to install packages into a custom (user) library. The path is set in the .Rprofile :
options(repos = c(CRAN = "https://packagemanager.posit.co/cran/latest"))
options(gargle_oauth_email = TRUE)
options(gargle_verbosity = "silent")
options(width=180)
.libPaths("/usr/local/lib/R/4.3/site-library")
See the result of the .libPaths() command in vsCode :
"/usr/local/lib/R/4.3/site-library"
"/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library"
So what could change to install packages again?
And where the dplyr package is installed :
find.package("dplyr")
[1] "/usr/local/lib/R/4.3/site-library/dplyr"
Good morning, Lionel. I have downloaded the new version of Positron and tested with two libraries. The result has been mixed, but I understand that the best will be to reinstall all the libraries again:
library(tidyverse) ── Attaching core tidyverse packages ──────────────────────────────────────────────────────────────── tidyverse 2.0.0 ── ✔ dplyr 1.1.4 ✔ readr 2.1.5 ✔ forcats 1.0.0 ✔ stringr 1.5.1 ✔ ggplot2 3.5.1 ✔ tibble 3.2.1 ✔ lubridate 1.9.3 ✔ tidyr 1.3.1 ✔ purrr 1.0.2
── Conflicts ────────────────────────────────────────────────────────────────────────────────── tidyverse_conflicts() ── ✖ dplyr::filter() masks stats::filter() ✖ dplyr::lag() masks stats::lag() ℹ Use the conflicted package to force all conflicts to become errors library(sf) Error: ! package or namespace load failed for ‘sf’ in dyn.load(file, DLLpath = DLLpath, ...): unable to load shared object '/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/Rcpp/libs/Rcpp.so': dlopen(/Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/Rcpp/libs/Rcpp.so, 0x0006): Library not loaded: /Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib Referenced from: <09319EC9-41A6-3C98-9398-634F252212C9> /Library/Frameworks/R.framework/Versions/4.4-x86_64/Resources/library/Rcpp/libs/Rcpp.so Reason: tried: '/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/Library/Frameworks/R.framework/Versions/4.3-x86_64/Resources/lib/libR.dylib' (no such file), '/Library/Frameworks/R.framework/Versions/4.3-x86_64/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) Hide Traceback ▆
- └─base::library(sf)
- └─base::tryCatch(...)
-
└─base (local) tryCatchList(expr, classes, parentenv, handlers) -
└─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]]) -
└─value[[3L]](cond)
@dsolito My workflow is to create versioned libraries. In my Renviron file (see usethis::edit_r_environ() I have something like:
R_LIBS_USER="~/R/library/%v/"
This causes .libPaths() to automatically interpolate the version and select that folder if it exists. Unfortunately R does not create these folders automatically so you need to make sure the folder exists (e.g. ~/R/library/4.4) every time you install a newer version of R.
We figured out that the fix works on my computer because I have disabled SIP (I'll reenable it to avoid such mistakes in the future).
Somehow ark is missing some entitlements to allow us to inject the path to libR on launch. @DavisVaughan has ideas about how to fix this.
My current theory is that the Positron entitlements are not actually being applied recursively down to ark https://github.com/posit-dev/positron/blob/67eb32a999def1e363c4f5fc812fc03499da0b70/build/azure-pipelines/darwin/app-entitlements.plist#L18
Chiming in with another instance of this happening:
Version Info
Positron Version: 2024.09.0 (Universal) build 77
Code - OSS Version: 1.93.0
Commit: 9b6f7c066546a4c7f104368fc769fb3768b08bfd
Date: 2024-09-23T02:43:50.589Z
Electron: 30.4.0
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Darwin arm64 23.5.0
R version 4.3.3 (2024-02-29)
- R installed via
rig 0.7.0 - I previously installed R via homebrew, but have since removed those installations and only install R via
rig
Repro and error
library(ggplot2)
Error:
! package or namespace load failed for ‘ggplot2’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so':
dlopen(/Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so, 0x0006): Library not loaded: /opt/homebrew/opt/r/lib/R/lib/libR.dylib
Referenced from: <91612CFD-59B3-3439-9352-F67F3A0ACE65> /Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so
Reason: tried: '/opt/homebrew/opt/r/lib/R/lib/libR.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/opt/homebrew/opt/r/lib/R/lib/libR.dylib' (no such file), '/opt/homebrew/opt/r/lib/R/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)
Hide Traceback
▆
1. └─base::library(ggplot2)
2. └─base::tryCatch(...)
3. └─base (local) tryCatchList(expr, classes, parentenv, handlers)
4. └─base (local) tryCatchOne(expr, names, parentenv, handlers[[1L]])
5. └─value[[3L]](cond)
find.package('ggplot2'):"/Users/sashimi/Library/R/arm64/4.3/library/ggplot2"
otool -L output
otool -L /Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so
/Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so:
glue.so (compatibility version 0.0.0, current version 0.0.0)
/opt/homebrew/opt/r/lib/R/lib/libR.dylib (compatibility version 4.3.0, current version 4.3.1)
/opt/homebrew/opt/gettext/lib/libintl.8.dylib (compatibility version 12.0.0, current version 12.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1971.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
Workaround
I ran the following to locate my packages:
.libPaths()
[1] "/Users/sashimi/Library/R/arm64/4.3/library"
[2] "/Library/Frameworks/R.framework/Versions/4.3-arm64/Resources/library"
I uninstalled R 4.3 using rig and deleted the /Users/sashimi/Library/R/arm64/4.3/library directory and reinstalled ggplot2.
Would like to report another instance of #3812, on a M1 MacBook Air with Big Sur (so ARM not Intel this time). Exit code was -1.
I resolved this issue for my friend by adding the following step to the building GitHub workflow and compiled an Ark binary through that:
- name: Set macOS 10.15 deployment target
run: |
echo "MACOSX_DEPLOYMENT_TARGET=10.15" >> $GITHUB_ENV
echo "RUSTFLAGS=-C link-args=-mmacosx-version-min=10.15" >> $GITHUB_ENV
I included this solution in https://github.com/posit-dev/ark/pull/946
In @sharon-wang's case where she previously had homebrew R and then switched to rig R for the same R version, I see
dlopen(/Users/sashimi/Library/R/arm64/4.3/library/glue/libs/glue.so, 0x0006): Library not loaded: /opt/homebrew/opt/r/lib/R/lib/libR.dylib
This suggests that her R package library (in /Users/sashimi/Library/R/arm64/4.3/library) was built against homebrew R, but homebrew R no longer exists. The rig version of R is not in /opt/homebrew/opt/r/lib/R/lib/.
The solution for her (and many others for this situation) is to never reuse an R package library when you are either:
- Upgrading a minor version of R
- Switching from homebrew R to non-homebrew R
Should we hook into dyn.load() or library.dynam() and detect mismatched libraries that came from a different distribution of R (rig vs homebrew, different R versions, etc), to give information to users about what happens and how they can fix it?
The implementation would differ by platform. But the general idea is that we'd look for hard-coded paths to libR libraries in the package's .so file, and see if that matches the R we're linking to. The implementation would be different for each platform so a bit tricky.
@lionel- @DavisVaughan Maybe 10.15 is a bit too old. but I wonder if Positron actually tests whether the current Ark is really comptabile with MacOS 11 as it currently claims?
I'm 100% sure that the current release version doesn't work for my friend by my custom version that sets the following does for her:
- name: Set macOS 11 deployment target
run: |
echo "MACOSX_DEPLOYMENT_TARGET=11" >> $GITHUB_ENV
echo "RUSTFLAGS=-C link-args=-mmacosx-version-min=11" >> $GITHUB_ENV
@kv9898 thanks for following up on that! Let's discuss in #10192 since that's a different problem than what's being discussed here. For this reason I'm going to mark our messages as off topic just to keep the discussion legible.