Hello guys,
Just a quick question,
Will R studio nd all tit's packages work on the new macOS update? Thank you!
Appears to, based on a quick workout, including one compilation of a package. Can’t guarantee everything, of course. On 2015 model Air Book.
1 Like
I upgraded to Big Sur last night. Big Sur is 11 for sure, but I saw the session info listed below, shown I am still running under macOS 10.16. It's possible that 10.16 was left in the final code because someone forgot to change the version. So far, my Rstudio and Tidyverse work fine., and my other R scripts/markdown are running without issues.
Just a reminder. If you want to try the new MacOs, I highly recommend using TimeMachine on your Mac before the upgrade.
Note: MacBook Pro (16-inch, 2019)
> sessionInfo()
R version 3.6.1 (2019-07-05)
Platform: x86_64-apple-darwin15.6.0 (64-bit)
Running under: **macOS 10.16**
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/3.6/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
other attached packages:
[1] googlesheets4_0.2.0 forcats_0.5.0 stringr_1.4.0 dplyr_1.0.2 purrr_0.3.4 readr_1.3.1 tidyr_1.1.2
[8] tibble_3.0.4 ggplot2_3.3.2 tidyverse_1.3.0
loaded via a namespace (and not attached):
[1] Rcpp_1.0.5 cellranger_1.1.0 pillar_1.4.6 compiler_3.6.1 dbplyr_1.4.4 tools_3.6.1 gargle_0.5.0 googledrive_1.0.1
[9] lubridate_1.7.9 jsonlite_1.7.1 lifecycle_0.2.0 gtable_0.3.0 pkgconfig_2.0.3 rlang_0.4.8 reprex_0.3.0 cli_2.1.0
[17] DBI_1.1.0 rstudioapi_0.11 curl_4.3 haven_2.3.1 xfun_0.16 withr_2.3.0 xml2_1.3.2 httr_1.4.2
[25] askpass_1.1 fs_1.5.0 generics_0.0.2 vctrs_0.3.4 hms_0.5.3 grid_3.6.1 tidyselect_1.1.0 glue_1.4.2
[33] R6_2.5.0 fansi_0.4.1 readxl_1.3.1 modelr_0.1.8 blob_1.2.1 magrittr_1.5 backports_1.1.9 scales_1.1.1
[41] ellipsis_0.3.1 rvest_0.3.6 assertthat_0.2.1 colorspace_1.4-1 tinytex_0.25 stringi_1.4.6 openssl_1.4.3 munsell_0.5.0
2 Likes
What does time machine do?
Time Machine is a built-in backup feature on your Mac. If some programs are not compatible with Big Sur, you can use Time Machine to recover your previous version of both files and software on your Mac.
1 Like
So far, no problems at all creating R Notebooks, running code, previewing as html, and installing/compiling packages. I am using preview version 1.4.1029 of RStudio and R 4.0.3 on a 2020 iMac.
I am teaching a forecasting class this term, with nearly all my current work using the tidyverts packages from Rob Hyndman and company, so do not have much experience with a wide variety of packages yet.
Outside of R/RStudio, the only glitch with Big Sur has been the lack of a driver for a 14 year old Epson printer (I am shocked!!). Fortunately, my 2012 Mac mini is running as a headless server with Catalina, which does have the driver, so can it share the printer over the network.
2 Likes
We've been extensively testing RStudio 1.4 with Big Sur. Early versions of Big Sur had some significant bugs related to RStudio, but RStudio is working well with the release version of Big Sur. Please let us know if you find anything that isn't working on Big Sur, but is working on older MacOS.
4 Likes
So far so good. I've compiled a few packages without issue, and all of my current projects work. One possible weak link is that if you compile packages that require 3rd party libraries, homebrew doesn't officially support Big Sur yet, but the libraries may still work.
I second @raydai's recommendation to make a bootable backup of your Mac OS X Catalina install before migrating to Big Sur.
UPDATE: I've had difficulties compiling sf and rgdal from source, where R crashes when I try to read geopackage files.
3 Likes
I am having trouble getting a few packages to load...
rgdal
tmap
rnaturalearth
in all cases, I get the same error "Error: package or namespace load failed for ‘tmap’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/Library/Frameworks/R.framework/Versions/4.0/Resources/library/sf/libs/sf.so':
dlopen(/Library/Frameworks/R.framework/Versions/4.0/Resources/library/sf/libs/sf.so, 6): Library not loaded: /usr/lib/libpq.5.dylib
Referenced from: /Library/Frameworks/R.framework/Versions/4.0/Resources/library/sf/libs/sf.so
Reason: image not found"
these worked before the upgrade to Big Sur
1 Like
Hey rick, I am also having the same issue. Have you had any luck?
This error message means that the sf, tmap, and rnatural earth packages are looking for a postgresql library that no longer exists in the /usr/lib directory.
The easiest way to deal with this is to reinstall the sf, tmap and rnatural packages as binary files., where this library will be included in the compiled packages.
I've only lightly exercised under Big Sur, but having been through previous combinations of migrations of macOS, R and system libraries I have a strong opinion.
You can wait for Saint Simon Urbanek to fix many packages requiring compilation of external libraries, such a gdal, on which packages such as rgdal depend—but he can't rejigger them all. We will always be in Blanche Dubois' condition of depending on the kindness of strangers because clang is not gcc.
If the difference in the macOS toolchain doesn't bother you because you are able to edit the source code to make compilation happy, then, of course, there's no problem.
Otherwise, the options are
- Patience
- Run a Debian VM under your macOS
- Migrate development to a dedicated Debian box
I say Debian because "it just works," to borrow a phrase. Other flavors of Linux work, too, but Debian is a de factor linga franca.
I've worked with UNIX derivatives since 1983. They all have their personalities. macOS is the most opinionated, and my take is that will always be reflected in R package installation issues like those surfacing in this thread.
2 Likes
This is unfortunately due to a change in macOS 11. The library /usr/lib/libpq.5.dylib, previously available on older versions of macOS, is no longer present -- and so binaries built to find this library in this location will fail to load.
This will hopefully be fixed soon, when new binaries of these affected packages are published on CRAN.
@jrmuirhead - I am encountering the same problem with geopackages. Have you found any fixes?
I have two different Rprojects, each with its own renv. Both run on sf 0.9-6, but link to different versions of gdal and proj (no idea how I managed that). One links to GDAL 3.2.0 and PROJ 7.2.0 (crashes) and one links to GDAL 3.1.1 and PROJ 6.3.1 (works).
I am reading in the exact same geopackage file (using sf::st_read(). And even trying to write a geopackage will make one of them fail.
I have tried, without luck, reverting the version of gdal, but can't get homebrew to do that for me. Any help would be appreciated!
I am running Big Sur on Mac, but here are the session infos for the one crashing:
R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS 10.16
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/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 datasets utils methods base
other attached packages:
[1] sf_0.9-6 ggplot2_3.3.2
loaded via a namespace (and not attached):
[1] Rcpp_1.0.5 pillar_1.4.6 compiler_4.0.2
[4] class_7.3-17 tools_4.0.2 digest_0.6.25
[7] evaluate_0.14 lifecycle_0.2.0 tibble_3.0.3
[10] gtable_0.3.0 pkgconfig_2.0.3 rlang_0.4.7
[13] DBI_1.1.0 rstudioapi_0.11 yaml_2.2.1
[16] xfun_0.15 e1071_1.7-3 knitr_1.29
[19] withr_2.2.0 dplyr_1.0.0 generics_0.0.2
[22] vctrs_0.3.2 classInt_0.4-3 rprojroot_1.3-2
[25] grid_4.0.2 tidyselect_1.1.0 glue_1.4.1
[28] here_0.1 R6_2.4.1 rmarkdown_2.3
[31] wesanderson_0.3.6 purrr_0.3.4 magrittr_1.5
[34] backports_1.1.8 scales_1.1.1 ellipsis_0.3.1
[37] htmltools_0.5.0 units_0.6-7 colorspace_1.4-1
[40] renv_0.11.0 KernSmooth_2.23-17 munsell_0.5.0
[43] crayon_1.3.4
And the one not crashing:
R version 4.0.2 (2020-06-22)
Platform: x86_64-apple-darwin17.0 (64-bit)
Running under: macOS 10.16
Matrix products: default
LAPACK: /Library/Frameworks/R.framework/Versions/4.0/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 datasets utils methods base
other attached packages:
[1] sf_0.9-6
loaded via a namespace (and not attached):
[1] Rcpp_1.0.5 rstudioapi_0.11 magrittr_1.5
[4] units_0.6-7 tidyselect_1.1.0 munsell_0.5.0
[7] colorspace_1.4-1 R6_2.4.1 rlang_0.4.7
[10] stringr_1.4.0 startR_0.1.0 dplyr_1.0.2
[13] tools_4.0.2 grid_4.0.2 gtable_0.3.0
[16] KernSmooth_2.23-17 e1071_1.7-3 DBI_1.1.0
[19] class_7.3-17 ellipsis_0.3.1 tibble_3.0.3
[22] lifecycle_0.2.0 crayon_1.3.4 purrr_0.3.4
[25] ggplot2_3.3.2 vctrs_0.3.2 glue_1.4.2
[28] stringi_1.4.6 compiler_4.0.2 UnidecodeR_0.02
[31] pillar_1.4.6 generics_0.0.2 scales_1.1.1
[34] classInt_0.4-3 renv_0.11.0 pkgconfig_2.0.3
UPDATE
This is not a long-term solution, but worked to get me through the day. I copied the renv files for sf from the working project to the crashing project, and that did it. Both projects link back to GDAL 3.1.1, which can read geopackages. R still thinks it's running under 10.16. Any actual fixes are welcome.
Hi @jcvdav,
No fixes yet, but to install the pre-compiled binaries of rgdal and sf from CRAN which uses Proj 6.3.1.
1 Like
I have the latest updates for both Big Sur and RStudio. I deal with biological data largely and rely on Bioconductor. Everything appears to be working well for us.
This topic was automatically closed 21 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.