Cygwin: unable to issue R CMD SHLIB foo.c - r

I am relatively new to R, and have no experience with Linux or C. I need to compile a .c program that I can later call from R. I installed Cygwin, and used the cd command to change to the R/R-2.14.0/bin directory. I verified this using the ls command. I also copied the foo.c program into the same directory. However, when I attempt to execute the "R CMD SHLIB foo.c" command I get the following error message:
-bash: R: command not found
Is there something else I need to do?

Actually, that was all I needed to know (that I needed to use RTools). I was using a hardcover reference, that recommended Cygwin.. but that turned out to be a dead-end for me. I installed RTools, and was able to compile the program, load it into R and execute it.

Related

R CMD build versus devtools::build() (Non-standard file/directory found at top level)

I am writing an R package and build and test it with:
Rscript -e "devtools::document()" && R CMD build . && Rscript -e "devtools::test();devtools::check()"
I get a note:
checking top-level files
Non-standard file/directory found at top level:
‘PosteriorBootstrap_0.0.1.tar.gz’
I get the note whether devtools::check() comes first or second.
This
thread suggests:
The note is telling you that you usually shouldn't have a file called
build in the top level of your package.
The tar.gz file is created by R CMD build and I get the same error even if I delete it before running it.
This
thread
suggests adding the tar.gz file to .Rbuildinore, which removes the note.
Another way to remove it is to run everything from devtools:
Rscript -e "devtools::document(); devtools::build(); devtools::load_all('.'); devtools::test(); devtools::check()"
And then I don't get that note.
What's the difference between R CMD build and devtools::build() and why does the former throw that note?
You are combining a number of steps that perform similar and/or competing functions. I would suggest reading this for a best-practice build and check workflow.
When you run R CMD build it builds the package to the current directory, which is the top level package directory. Therefore, when you run your checks, it sees the .tar.gz file in the package root, which is a non-standard file to have in a package, thus the warning. devtools::build() is smart and builds the package to the package parent directory (regardless of where you are calling it from). Trying to call R CMD commands mixed with devtools functions can create issues, because devtools also calls R CMD commands, so you may be duplicating actions at various points in time or causing commands to be called in the incorrect order.
Per the link above, a best-practice workflow would be:
Rscript -e "devtools::document();devtools::check();devtools::build()"
called from the package root, and you avoid dealing with R CMD altogether. If you want to use R CMD it would look something like this:
Rscript -e "devtools::document()" && cd .. && R CMD build PosteriorBootstrap && R CMD check PosteriorBootstrap*.tar.gz
starting in the package root and then changing to the parent directory.

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 =

How do I debug a segfault which only occurs during vignette building?

I have Rcpp-based C++ code with a memory access bug which is only revealed when compiling vignettes (both in classic R and devtools manners).
The crashing code runs fine on its own in vanilla R environment.
I've tried things like:
R -d gdb --vanilla -e "devtools::build()"
R -d gdb --vanilla -e "devtools::check()"
but after digging deep I find that both devtools and R start new processes to build the vignettes during either building or checking a package.
I therefore modified /usr/lib/R to always be invoked -d gdb -ex run but this wouldn't run because it messed up the complicated argument passing between each of the steps.
I've no idea how to proceed at this point as I can't even reproduce the error with a simple R command invoking the compiled code. Could this be an unexpected interaction of Rcpp or other packages which differs between the vignettes building and vanilla interactive environment?

R CMD check with specified library path

I am working on a package which I can load using devtools. But
R CMD check asm
gives me an error message
Error : package ‘seedDisp’ required by ‘asm’ could not be found
Which is kind of obvious as it is not installed in the global library.
But: I have installed installed in a local library (./library) and I have a .Rprofile file in the directory from which I run the checks as follow:
.libPaths(normalizePath("library"))
So when I run R and use devtools and load_all(.) it loads as the package seedDisp is installed.
It seems that R CMD check does ignore the library location which is set via the .Rprofile file.
So I tried
R CMD CHECK -l ./library asm_0.0.1.tar.gz
but it seems that -l only is used to install in and not to look for installed packages.
How can I tell R CMD check to look for installed packages in the library at ./library ?
One way to do this is via the R_LIBS_USER variable so I generally do
R_LIBS_USER=/some/other/path R CMD check asm_0.0.1.tar.gz
If that variable is generally set on your system, you need to do the usual trick of appending, or just set it in your shell via e.g.
export R_LIBS_USER="/some/other/path:${R_LIBS_USER}"
R CMD check asm_0.0.1.tar.gz
This mechanism is independent of how you call R CMD check it will work with or with devtools.

permission denied error while building/checking R package on WIndows

I tried to build the R package hyperSpec using Windows Vista. When I do so, I get the following error message:
warning in file.copy(pkgname, Tdir, recursive = TRUE)
Problem copying .\hyperSpec\data\barbiturates.rda to C:\Users\JenZIG\AppData\Local\Temp\RtmpOEIqBD\Rbuilde446d3a290d\hyperSpec\data\barbiturates.rda: Permission denied
It is all the same whether I use the command line with R CMD build or R Studio's Build Tools (RTools installed, all package dependencies installed).
To solve the problem, I tried to change the path for the temporary directory or to manually set the permissions for the folders but without success. I tried to execute everything as administrator but again no success.
I think, a similar problem was discussed here:
https://stat.ethz.ch/pipermail/r-devel/2013-April/066389.html
However, there is no solution provided for this problem.
In addition, I have the same problem when I try to build the package with Win7.
I had this problem. I had previously installed the package in question using the command line:
sudo R -e "install.packages('somepackage', repos='http://cran.rstudio.com/')"
Then when I tried building the somepackage package from source I got the permission denied message.
The solution was to run the following from the command line:
sudo R -e "remove.packages('somepackage')"
Then I was able to build and check somepackage from source.
EDIT
I see that the original question was specific to Windows. In that case I think you simply need to run a powershell window as administrator and use the following command:
Rscript.exe "remove.packages('somepackage')"
What worked for me was unloading the package, removing the package, restarting R Studio, and then reinstalling it.
(in R Studio on the right hand side of the interface there is a tab called "Packages" that lets you do all of these things)

Resources