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.
Related
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
I am the mantainer of few R packages that use Rcpp for some core calculations. Wishing to try a new feature of the Rcpp package as described in Rcpp 0.12.18 Rbloggers
To do so I did the following:
I created a Makevars and Makevars.win in my scr folder, both contaning the line CPPFLAGS += -DRCPP_USE_UNWIND_PROTECT
I added the SystemRequirements: GNU make entry in the DESCRIPTION file.
Btw that raises some issues that I wounder will make my package rejected on CRAN:
following Warning message in compiling my package:
checking compilation flags in Makevars ... WARNING Variables overriding user/site settings: CPPFLAGS: -o /dev/null -DRCPP_USE_UNWIND_PROTECT
Note: GNU make is a system requirement
I would like to know if it is possible to rewrite the Makevars to remove the warning and possibly, the Gnu make requirement
Thanks in advance for the attention
You want to use PKG_CPPFLAGS (or PKG_CXXFLAGS) as that is the per-package variant. What you altered is the system-wide version hence the warning.
More details are as always in the Writing R Extensions manual, otherwise the many existing example packages (all on CRAN and browseable at GitHub) can help too.
For example, here is the one-toggle-setting use case from the RcppExamples package:
PKG_CXXFLAGS = -DRCPP_NEW_DATE_DATETIME_VECTORS
(which is strictly-speaking no longer needed as the "new" Date and Datetime vector classes became the default a while ago).
Also, if you use this form you do not need the += and have no requirement to declare on GNU make -- another win.
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 =
Trying to compile R-3.3.2 on Debian Jessie, all dependencies are installed. However the ./configure script complains about the zlib/bzip2 library versions not matching with the minimum requirement.
Minimum version required:
zlib: 1.2.6 (installed version: 1.2.11)
bzip2: 1.0.6 (installed version: 1.0.6)
After looking at the parts of configure script checking the library versions, it seems that it compares versions with strcmp or strncmp. Since "1.2.11" is lexicographically smaller that "1.2.6" it return a non-zero value indicating that the match failed. Besides, it just compares the first 5 characters which is also not what it is intented. So, it's a bug in configure script. Changing the script fixed the issue.
For zlib, find this line:
exit(strncmp(ZLIB_VERSION, "1.2.5", 5) < 0);
Change it to:
exit(ZLIB_VERNUM < 0x1250);
I had some issues installing R myself, specifically with the error
checking for BZ2_bzlibVersion in -lbz2... no
I had to install libbz2-dev to get that error to go away.
Unfortunately, I came across a few more issues while running ./configure and had to do a little more digging to find out how to solve it.
Discussion on issue
After reading that, I had realized I had to install a couple packages like libcurl4-openssl-dev, libpcre3, and liblzma-dev to finally finish the configuration.
The cited link suggested
At this stage you could have as well tried to install R 3.2.0RC ...
R-devel has not yet diverged much.
Personally, I think that installing an older version to resolve dependency issues reeks of laziness, but that's just my two cents.
I am working on an R package containing Fortran source files. The structure of the Fortran code is rather complex, with many dependencies, therefore I have a Makefile in the src folder for the compilation of the shared library.
So far I have been compiling this package on my machine running Ubuntu 14.04, without any problems. I am now trying to compile it on Windows using Rtools, and I am running into a problem when linking the objects to produce the shared library. More precisely, the linker does not find the functions REXIT, RWARN and RCHKUSR, as I get the following error messages:
undefined reference to `rchkusr_'
undefined reference to `rexit_'
undefined reference to `rwarn_'
These functions are supposed to be in the shared library R.dll (libR.so under Linux). I checked this library with Dependencies Walker and I could find these functions. I have tried to link with -I C:/Program\ Files/R/R-3.1.1/bin/i386/R.dll to make explicit the reference to the shared library. I have tried to recompile with -fno-underscoring to make sure the underscores were not the problem. Nothing helped.
Any ideas where the problem could come from? Any suggestions would be more than welcome!
Under Linux I did not have to do anything special, the linker found the functions without specifying anything in the Makefile.
I am using R version 3.1.1 and Rtools version 3.1.
Many thanks for your help.
After fiddling with the Makefile, I finally found the solution to my problem: The flags I was trying to pass to the linker were wrong. Only the path of the shared library R.dll should be specified, using -L, and the name of the library should be specified using the flag -lR at the end of the command. In short, I specified
gfortran -shared *.o -o myLib.dll -L C:/Program\ Files/R/R-3.1.1/bin/i386 -lR
to create myLib.dll and it worked! I guess I got confused because under Linux there is no need to specify anything, the linker finds the shared library on its own.
Probably not the best and most portable solution I can get (I now have two Makefiles to deal with, Makefile for Linux and Makefile.win for Windows...), but good enough for now.