Resolve issues installing R packages after switch from Intel to apple silicon - r

I just migrated things over from my old mac to my my new mac (Intel to Apple Silicon), installed the latest version of R, ran brew upgrade, and began updating R packages. Many needed to be reinstalled, some from source. I bumped into several issues.
Library linkages not being found (e.g., Mac OS Big Sur R compilation error: ld: framework not found CoreFoundation)
for CRAN packages, having the CRAN mirror selection pop up in a weird X11 GUI window instead of a numeric selection in the R console (which was the previous behavior).
I didn't really want to troubleshoot each library issue. I got the sense that ~/.R/Makevars and ~/.Rprofile might need to be edited. What did I need to do to make these problems go away?

A few resources were helpful, but some seemed out of date or incomplete. Here is my attempt to give a full step-by-step recreation of what I think worked, and I will edit as needed while I get my new system up and running.
Based largely on the recommendations here, I edited the Makevars file as follows:
In the shell:
vi ~/.R/Makevars
I then hit i (for insert) and deleted Everything that was there. I then added:
LDFLAGS += -L/opt/homebrew/opt/libomp/lib
CPPFLAGS += -I/opt/homebrew/opt/libomp/include
FLIBS =-L/opt/homebrew/opt/gfortran/lib
F77 = /opt/homebrew/bin/gfortran
FC = /opt/homebrew/bin/gfortran
CFLAGS = -I/opt/homebrew/include
CPPFLAGS = -I/opt/homebrew/include
CXXFLAGS = -I/opt/homebrew/include
To save, I hit esc and then :x to save and close.
AFAIK, this resolved the issues with library finding/loading/linking, and I have installed several packages from source without error now.
To deal with the annoying pop-out GUI window to select the CRAN mirror, I edited the ~/.Rprofile (also using vi as described above) to read:
local({r <- getOption("repos")
r["CRAN"] <- "https://cloud.r-project.org"
options(repos=r)
})
options(menu.graphics = FALSE)
This was based on the best looking answers to this old but still important question

Related

How to override compilers used by R?

When I try to compile R packages from source, it uses the compilers and settings defined in etc/Makeconf within the R installation directory. How can I override these settings?
I have an ~/.R/Makevars file (suggested e.g. here), and I included the settings I want there, but these are not being used for some reason. Why not, and how can I fix this?
I could not find the official documentation on ~/.R/Makevars and Makeconf—links would be welcome.
In the past, this very same setup used to work correctly for me, but recently it doesn't. I assume something must have changed in recent R versions, but I am not sure when. Were there any recent changes that could have affected this?
Motivation and context:
I am on macOS and I want to use gfortran from MacPorts. Thus I set FC = /opt/local/bin/gfortran-mp-11 and FLIBS = -L/opt/local/lib/gcc11 -lgfortran -lquadmath -lm in ~/.R/Makevars. However, the system still wants to use a gfortran installation in /usr/local, which does not exist on my machine. It clearly takes the paths and options from etc/Makeconf. I am using the official R binaries.
It turns out that the reason why ~/.R/Makevars was ignored on my machine when trying to build a certain package was a bug in withr:
https://github.com/r-lib/withr/issues/169
Installing the development version of withr using devtools::install_github("r-lib/withr#master") fixed the problem.

Building the R package, "later," generates undefined symbol

Updating installed packages for R-3.5.2 (in Slackware-14.2) the "later" package fails to load because of this error:
/usr/lib/R/library/later/libs/later.so: undefined symbol: __atomic_fetch_add_8,
Web searches and folks on the r-help mail list were not able to resolve this issue.
Earlier versions of "later" had no problems installing and updating.
All suggestions will be followed up.
Issue #73 on github discusses that on some platforms, one needs to add a flag -latomic even though std::atomic is part of the C++11 standard library.
Assuming you have C++11 installed on your Slackware 14.2, you should be able to:
git clone https://github.com/r-lib/later.git
nano later/src/Makevars # or whatever editor you prefer
# Change `PKG_LIBS = -pthread` to `PKG_LIBS = -pthread -latomic`
sudo R CMD INSTALL later
Update December 2019:
With the latest version of later, it now is:
git clone https://github.com/r-lib/later.git
nano later/src/Makevars.in # or whatever editor you prefer
# Change `PKG_LIBS = -pthread #extra_pkg_libs#` to `PKG_LIBS = -pthread -latomic #extra_pkg_libs#`
sudo R CMD INSTALL later

R is using the mingw_32 to compile packages for 64-bit architecture

Periodically – I think whenever I update R – I have problems installing packages from source on my 64-bit Windows machine.
Today I'm trying to install a package using devtools::install_github(). The installation proceeded fine on my laptop, but my not on my desktop, which can install the package under *** arch - i386, but under *** arch - x64, which reports the error message
C:/PROGRA~1/R/R-34~1.4/bin/x64/R.dll: file not recognized: File format not recognized
The command that caused the error is
C:/Rtools/mingw_32/bin/g++ -shared -s -static-libgcc -o PACKAGENAME.dll [...]
I believe that the error is arising because R is using mingw_32 to attempt to compile a 64-bit package. The question is, where can I tell R to use mingw_64? I've already checked all the places that I can recall:
R-3.4.4/etc/x64/Makeconf states
BINPREF ?= c:/Rtools/mingw_64/bin/
My system PATH (verified from within R using Sys.getenv('PATH')) includes mingw_64 ahead of mingw_32.
R must be looking somewhere else to decide which compiler to use... but where?
Via R CMD check not looking for gcc in Rtools directory:
R was looking in C:/Users/MYUSERNAME/Documents/.R/Makevars for the value of BINPREF. Deleting the contents of this file removed the incorrect location.
$RPATH/etc/i386/Makeconf is re-created with each new installation of R, and contains the line
BINPREF ?= c:/Rtools/mingw_32/bin/.
The ?= operator will set the value of BINPREF if it is not already set, as it was in the Makevars file mentioned above. So replacing ?= with = will work until a new version of R is installed and the Makeconf file is overwritten – updating, or uninstalling, R will not modify the Makevars file in the User directory.
If you start digging from devtools::install_github, it will lead you through the following functions:
devtools::install_github
devtools:::install_remotes
devtools:::try_install_remote
devtools:::install_remote
devtools:::install
devtools:::check_build_tools
devtools:::setup_rtools
devtools:::scan_path_for_rtools
And when you run the following code:
devtools:::scan_path_for_rtools(TRUE)
devtools:::setup_rtools(debug=TRUE)
Most likely, it is saying that Rtools is not currently installed. (Yes, a bit counterintuitive given that you already have it installed in C:/Rtools but maybe not registered in registry)
To fix it, you will need to run (which is in essence the solution in Rtools is not being detected from RStudio)
Sys.setenv(PATH=paste0("C:\\Rtools\\bin;", Sys.getenv("PATH")))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_64/bin", version=3.4), class="rtools"))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_32/bin", version=3.4), class="rtools"))
Please let me know if this works.
BINPREF ?= c:/Rtools/mingw_64/bin/
remove ? before =

R cmd check not locating texi2pdf on mac after R 3.1.3 upgrade

Does anyone have a link to clear instructions on how to install and configure the necessary latex packages to build R packages on a mac?
I have some scripts for building and checking R packages on a mac server. They seemed to work fine, but after upgrading to R 3.1.3, many of the packages started failing with
Error in texi2dvi(file = file, pdf = TRUE, clean = clean, quiet = quiet, :
Running 'texi2dvi' on 'networkVignette.tex' failed.
Messages:
sh: /usr/local/bin/texi2dvi: No such file or directory
Calls: <Anonymous> -> texi2pdf -> texi2dvi
Execution halted
I found a thread which seemed to suggest I need a more recent version texinfo (5.2) than what is installed by default. And apparently I've I've got the wrong version installed in the wrong location?
which texi2pdf
/sw/bin/texi2pdf
texi2pdf --version
texi2pdf (GNU Texinfo 5.1) 5234
(same version is reported when running system('texi2pdf --version') in R )
This thread gives a link to a texinfo 5.2 source collection:
http://r.789695.n4.nabble.com/R-CMD-build-looking-for-texi2dvi-in-the-wrong-place-R-devel-td4701706.html
But I'm not familiar with installing executable from a tar.gz file on a mac. The R mac help pages I found suggest installing MacTex, which I tried but that didn't seem to help.
** Update: ** additional discussion of related problems on R-SIG-mac mailing list:
https://groups.google.com/forum/#!topic/r-sig-mac/xjyuFdl5Ezk
Update:
Here is where I'm currently at:
I removed my /sw directory to uninstall fink and all of its packages (couldn't figure out how to upgrade it)
installed homebrew
brew install texinfo installs version 5.2 the package,
but generates the message This formula is keg-only, which means it was not symlinked into /usr/local and actually installs in in /usr/local/Cellar/texinfo/5.2/bin which means it is not on the path and R won't find it.
manually symlink each of the texi2pdf, texi2dvi , etc as vincent suggests (this is because R has the /usr/local/bin location as default in the tools::texi2dvi function?
edited the /etc/paths file on the system to add /usr/local/bin so that finds the brew installed 5.2 version before it finds it before the osx system supplied version 4.6 version. This may not be necessary because R has it hardcoded?
All of this gets rid of the "can't find texi* errors", and gives me a bunch of latex errors (which I don't see on unix and windows builds) so I'm still kind of stuck.
This seems very hackish, so there must be a cleaner way? But it sounds like stuff with tex and mac is very sketchy at the moment? https://tex.stackexchange.com/questions/208181/why-did-my-tex-related-gui-program-stop-working-in-mac-os-x-yosemite
This worked for me on Mavericks and on Yosemite:
ln -s /usr/bin/texi2dvi /usr/local/bin/texi2dvi
ln -s /usr/bin/texi2pdf /usr/local/bin/texi2pdf
On my Lion system both the command which texi2pdf at a Terminal/bash prompt and from a R.app GUI prompt tell me that I have that program in:
system("which texi2pdf")
#/opt/local/bin/texi2pdf
That is a location typical for MacPorts installation. I think the /usr/local/bin/ is what the binary R version "expects". I'm not really that UNIX savvy, but I think the you can modify the PATH environment variable so that R will be able to find your installation. (Whether it will be compatible I cannot say since so much detail is missing from your question.) My Tex installation is MacTex, which I got from https://www.tug.org/mactex/. I admit to having a cobbled-together system:
system("echo $PATH")
# /opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin
That gets set at the beginning of an R session because this is the first line in my .Rprofile-(invisible)file:
Sys.setenv(PATH="/opt/local/bin:/opt/local/sbin:/sw/bin:/sw/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/texbin:/usr/X11/bin:/usr/X11R6/bin")
I think /sw/bin/ installations signify a fink install, which I have had very little success with. Simon Urbanek suggests not using any package installers, but then leaves the rest of us UNIX weenies very little in the way of worked examples of how to install that various external packages that underpin the many interesting and oh-so-useful R packages. So I feel your pain, but I'm not running for President.
So I suppose you could try this at your R console before again attempting one of the earlier unsuccessful installs:
Sys.setenv(PATH=paste( Sys.getenv()$PATH, # should be the character string of the $PATH
"/sw/bin/", sep=":")
)
Wish I could offer guarantees, but if it breaks the only guarantee is that you get to keep all the pieces.
I ran into a similar error message using Mavericks 10.9.5 (factory configured) and R 3.1.
It turns out that I didn't have pdfLaTex. I went to this page: http://tug.org/mactex/ and downloaded the MacTex installation package. It's big (>2GB) but after I installed it, my R package build problems went away.
Hope this might be helpful to anyone else who runs into this error message.

Error installing and running rcpp

I'm pretty new to R so apologies for a stupid question. I'm trying to get rcpp running but I'm stuck in an endless loop of R asking me to re-install RTools.
I broadly followed the code in this blog post, although first time off I installed everything by hand & I've subsequently re-installed everything a few times over. I'm running Windows 7, R version 3.1.2, R Studio Version 0.98.1091 (not that this should matter much) and RTools 3.1.
An edited highlight of what my console looks like is as follows:
> library(installr)
Welcome to installr version 0.15.3...
> install.Rtools()
Loading required package: devtools
No need to install Rtools - You've got the relevant version of Rtools installed
> find_rtools()
[1] TRUE
> library(Rcpp)
> evalCpp("1+1")
Error in sourceCpp(code = code, env = env, rebuild = rebuild, showOutput = showOutput, :
Error 65535 occurred building shared library.
At which point a dialog box pops up saying:
Install Build Tools
Compiling C/C++ code for R requires installation of additional build tools.
Do you want to install the additional tools now?
And then I get directed to download and re-install RTools 3.1 from cran all over again.
I've seen that this can be an issue with the PATH variable but I've tried various things including:
Nothing (extra) in the PATH variable
Including both references to R (C:\Program Files\R\R-3.1.2\bin\x64) and RTools (C:\RBuildTools\3.1\bin;C:\RBuildTools\3.1\gcc-4.6.3\bin;) in the PATH. Once with RTools first, once with R first
Including just a reference to RTools in the PATH as the initial install file directed me to do.
Any ideas on things to try would be gratefully accepted!
EDIT
Following Dirk's comment it looks like I might have a problem with how RTools is installed. I've followed the instructions from several blogs / tutorials on how to install RTools; all to no avail (yet!)
This GitHub page gives some instructions on how install and check that the installation has worked. I've followed all the checks (see below for copy of the console) and it looks like I have a working install of RTools, but when I try to run evalCPP() again I get the same error as before directing me to install RTools.
> Sys.getenv('PATH')
[1] "C:\\Program Files\\R\\R-3.1.2\\bin\\x64;C:\\RTools\\bin;C:\\RTools\\gcc-4.6.3\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files (x86)\\Enterprise Vault\\EVClient\\;C:\\Program Files (x86)\\Microsoft SQL Server\\100\\Tools\\Binn\\VSShell\\Common7\\IDE\\;C:\\Program Files (x86)\\Microsoft SQL Server\\100\\Tools\\Binn\\;C:\\Program Files\\Microsoft SQL Server\\100\\Tools\\Binn\\;C:\\Program Files (x86)\\Microsoft SQL Server\\100\\DTS\\Binn\\;C:\\Program Files (x86)\\Microsoft Visual Studio 9.0\\Common7\\IDE\\PrivateAssemblies\\;C:\\Program Files\\Microsoft SQL Server\\110\\Tools\\Binn\\;C:\\Program Files\\Microsoft\\Web Platform Installer\\;C:\\Program Files (x86)\\Microsoft SDKs\\TypeScript\\1.0\\;C:\\Program Files\\Microsoft SQL Server\\100\\DTS\\Binn\\"
Warning message:
printing of extremely long output is truncated
> system('g++ -v')
Using built-in specs.
COLLECT_GCC=C:\RTools\GCC-46~1.3\bin\G__~1.EXE
COLLECT_LTO_WRAPPER=c:/rtools/gcc-46~1.3/bin/../libexec/gcc/i686-w64-mingw32/4.6.3/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /data/gannet/ripley/Sources/mingw-test3/src/gcc/configure --host=i686-w64-mingw32 --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/mingw32 --prefix=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/mingw32 --with-gmp=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --with-mpfr=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --with-mpc=/data/gannet/ripley/Sources/mingw-test3/mingw32mingw32/prereq_install --disable-shared --enable-static --enable-targets=all --enable-languages=c,c++,fortran --enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --disable-werror --enable-checking=release --disable-win32-registry --disable-rpath --disable-werror CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer' LDFLAGS=
Thread model: win32
gcc version 4.6.3 20111208 (prerelease) (GCC)
> system('where make')
C:\Rtools\bin\make.exe
I've also had a look at Appendix D of R Installation and Admin. I can't see anything in here I've not already tried except for section D.4 which implies I might need to rebuild rcpp from source using my installed RTools. I don't have time to do this right away but will give it a try unless people say this route is not worth my time.
EDIT v2
So I tried building rcpp from source ... and that didn't work either. I downloaded both the package source and windows binaries from the CRAN Rcpp package page. In the R console I now get:
> install.packages(pkgs = "C:/Rcpp_0.11.4.tar.gz", repos = NULL, contriburl = NULL, type = "source", verbose = TRUE)
Installing package into ‘C:/Users/james.macadie/Documents/R/win-library/3.1’
(as ‘lib’ is unspecified)
system (cmd0): C:/PROGRA~1/R/R-31~1.2/bin/x64/R CMD INSTALL
Warning in install.packages :
package ‘C:/Rcpp_0.11.4.tar.gz’ is not available (for R version 3.1.2)
I guess my active questions now boil down to:
Reading the whole of the post above can anyone tell me how to fix things so it just works? Or, failing that...
What tests can I run to check I really do have Rtools installed correctly? Everything I have found on the internet suggests I do: system('where make') etc. However, the evidence of being unable to run evalCpp or other rccp functions suggests I don't.
What am I doing wrong when building from source? Should I try the command line option?
EDIT v3
Running evalCpp with showOutput= TRUE and verbose = TRUE I think I've tracked the error back to R CMD SHLIB not working. I followed this blog, which shows how to work with the command line R directly. However when I get to the line R CMD SHLIB sequence_examples.c the execution just skips straight to the next command line without doing anything, generating any files in the directory or throwing any errors. I tried running the --help options at the command line but get the same sort of error:
C:\Users\james.macadie> R --help
Or: R CMD command args
where 'command' is one of:
INSTALL Install add-on packages
REMOVE Remove add-on packages
SHLIB Make a DLL for use with dynload
BATCH Run R in batch mode
build Build add-on packages
check Check add-on packages
Rprof Post process R profiling files
Rdconv Convert Rd format to various other formats
Rdiff difference R output files
Rd2pdf Convert Rd format to PDF
Rd2txt Convert Rd format to pretty text
Stangle Extract S/R code from vignette
Sweave Process vignette documentation
config Obtain configuration information about R
open Open a file via Windows file associations
texify Process a latex file
Use
R CMD command --help
for usage information for each command.
C:\Users\james.macadie> R CMD SHLIB --help
C:\Users\james.macadie>
N.B. for people reading the earlier code samples higher up this post I have changed a few things since those code snapshots:
I've installed R directly into C:\R. It used to be in C:\Program Files\R\ but as has been suggested file paths with spaces in can cause problems
I'm referencing Rtools under C:\Rtools\ and not C:\RBuildTools\
Thanks for any suggestions, as ever
Had the same endless loop issue when trying to install Twitter's BreakoutDetection (which is also written in cpp)
fixed by executing the following
Sys.setenv(PATH="%PATH%;C:/Rtools/gcc-4.6.3/bin;c:/Rtools/bin")
and then answering "no" when presented with the following prompt:
"Install Build Tools Compiling C/C++ code for R requires installation of additional build tools. Do you want to install the additional tools now?"
Didn't try these actions independently so not sure if either on their own would have fixed the issue
I found that ensuring all of these were in my path fixed it. I did this with RStudio closed; I didn't reboot after.
C:\Program Files\R\R-3.1.3\bin\x64
C:\Program Files\R\R-3.1.3\bin
C:\RBuildTools\3.2\bin
C:\RBuildTools\3.2\gcc-4.6.3\bin64
C:\RBuildTools\3.2\gcc-4.6.3\bin
C:\RBuildTools\3.2\gcc-4.6.3\i686-w64-mingw32\bin
These are on my Win7-64bit computer. YMMV, and I'm mostly posting this to ensure others see it if they are having the same issue.
In the end it was something a bit left-field. Inspired by the following post, I had a look at the ComSpec environment variable. Not quite sure how, but I had it set to "cmd.exe".
Removing the double quotes, so it said cmd.exe, and then rebooting fixed everything.
Thanks to all who've tried to help.
I experienced the same problem, I fixed this problem by adding Rtools dir into env variables:
Sys.setenv(BINPREF = "C:/Rtools/mingw_$(WIN)/bin/")

Resources