Rtools not recognized on Win 10, R 3.6.1, RStudio 1.2.5001

Hi,

I have been developing a personal package for a while on Win 7 Enterprise, Service Pack 1, with RStudio 1.2.5001 and R 3.6.1. In this system all needed to do is to download Rtools from CRAn and run the exe and install Rtools under C (C:\Rtools). After that, from RStudio project environment when I clicked Build > Install and Restart, everything worked fine.

Recently I moved to Win 10 environment, with the same setup of R 3.6.1 and RStudio 1.2.5001. I installed Rtools and ran the exe, but this did not work. Whenever I wanted to build my package RStudio cannot find the Rtools. Rtools is under C:\Rtools, same as my old system.

Here is my Sys.info():
sysname: "Windows"
release: "10 x64"
version: "build 17134"

RStudio Edition : Desktop
RStudio Version : 1.2.5001
OS Version : Windows 10
R Version : 3.6.1

I read about the PATH issues and tried all the suggestions. I added the Rtools directories under the system path, created the BINPREF variable, created a .Renviron file under Documents and included the path there, etc. Nothing worked.

As far as I can tell, the problem seems to be coming from the cpp.exe not being found or cannot be used. Here are the tests I did and results:

find_rtools()
[1] TRUE

Sys.getenv("PATH")
[1] "C:\Users\kartalcb\Documents\R\R-3.6.1\bin\x64;C:\Rtools\bin;C:\Rtools\mingw_64\bin; .... other stuff...

Sys.getenv("BINPREF")
[1] "C:\Rtools\mingw_64\bin\"

pkgbuild::find_rtools(debug = TRUE)
Scanning R CMD config CC...
cc_path: C:\Rtools\mingw_64\bin\gcc
install_path: C:/Rtools
Found compatible gcc from R CMD config CC
[1] TRUE

pkgbuild::check_rtools(debug = TRUE)
Scanning R CMD config CC...
cc_path: C:/Rtools/mingw_64/bin/gcc
install_path: C:/Rtools
Found compatible gcc from R CMD config CC
[1] TRUE

pkgbuild::rtools_path()
[1] "C:/Rtools/bin"

.Call("rs_canBuildCpp")
[1] FALSE

pkgbuild::has_build_tools()
[1] FALSE

pkgbuild::has_build_tools()
[1] FALSE

In my old system, .Call("rs_canBuildCpp") returns TRUE even though the Sys.getenv("BINPREF") returns " " (empty string).

I tried every version of the suggestions, nothing worked. I have the same permissions as my old system, I have write permission to C, the R is installed under C:\Users\kartalcb\Documents\R\R-3.6.1.

Any suggestion would be much appreciated.

Have you tried moving the rtools directory up the system path? I've had problems like this in the past but can't recall the details. I do know that Rtools sometimes installs in RBuildtools by default. I also had a problem with a utility app. Hm, according to this code recent version of Rtools aren't working...

# https://stackoverflow.com/questions/48886065/rcpp-does-not-find-rtools
library(installr)
install.Rtools(choose_version = TRUE) # C:\RTools\3.4 (3.5 not working)

# https://github.com/r-lib/devtools/issues/1772
library(devtools)
assignInNamespace("version_info", c(devtools:::version_info, list("3.5" = list(version_min = "3.3.0", version_max = "99.99.99", path = "bin"))), "devtools")
find_rtools() # is TRUE now

library(Rcpp)
evalCpp("1+1")

Hi,

Thank you for your response. Here is the situation:

The rtools directory is already at the top of the path. I did not install rtools through RStudio, i downloaded it from CRAN and ran the exe file, which installed rtools under c:\rtools as always.

My problem seems to be quite unique because I can install from a tar.gz file, I just cannot build the package.

I discovered something else yesterday. When I open my package project RStudio automatically sets the working directory to the project folder. getwd() confirms this. When I click Build > Install and Restart, it offers me to install rtools and I get the error

==> Rcmd.exe INSTALL --no-multiarch --with-keep.source ScorecardBahar

Warning: invalid package 'ScorecardBahar'
Error: ERROR: no packages specified

Exited with status 1.

However, when I click Build Source Package it starts building the package and then throws an error saying that C:\Windows\System32 is un-writable. So I started RStudio as an administrator and clicked Build Source Package. It did build the package, saying that the tar.gz file is saved under the project path. BUT, it was not actually saved there. It was saved under System32 path! I discovered that System32 was my command prompt's default home directory. So changed it to My Documents and tried again. RStudio builds the package, says the package is saved under the parent folder of the project folder, but it actually saved the tar.gz file under My Documents!

This is not a real solution to my problem because obviously there is path recognition problem going on, but at least I can build the package.

Hi,

I just ran

assignInNamespace("version_info", c(devtools:::version_info, list("3.5" = list(version_min = "3.3.0", version_max = "99.99.99", path = "bin"))), "devtools")

and got the error: Error in bindingIsLocked(x, ns) : no binding for "version_info"

What does this mean?

Are you on a network? Did the network admin change the permissions?

Have you got package ScorecardBahar installed? Could be a bad package install in a dependency? Or is that the name of your package?

I am on a network, but I have elevated rights and my permissions are exactly the same as the time I had my old system, where everything worked just fine.

That is the name of my package. It is good, I am using it on other systems and on my new system as well.

The problem is not with the package, I am sure about that. In win 10, RStudio can mixes up the directories somehow and including them in the system PATH does not help. I need the .Call("rs_canBuildCpp") to return TRUE, but it odes not. I think this function does not look at the system PATH. I am trying to figure out the location it looks at, but I could not find anything on the net.

Bahar

Does setting:

Sys.setenv(BINPREF = "C:/Rtools/mingw_$(WIN)/bin/")

make a difference for you?

I believe think that you need to use forward slashes rather than backslashes in BINPREF as well.

Hi,

I tried both forward and backward slashes. It does not make any difference. In both cases R can get the path, but it does not help with my case. I also tried to set the BINPREF as you suggested, again no difference.