Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RStudio do not find Rtools and offer to install even if already installed #3563

Closed
cderv opened this issue Sep 30, 2018 · 56 comments
Closed
Milestone

Comments

@cderv
Copy link
Collaborator

@cderv cderv commented Sep 30, 2018

System details

RStudio Edition : Desktop
RStudio Version : 1.2.1013 
OS Version      : Windows 10
R Version       : 3.5.1

Steps to reproduce the problem

On a windows machine with R 3.5.1,

  • install Rtools in C:/Rbuildtools.
    This is the path by default where the installer install Rtools. The installer is the one that you get when your are inside Rstudio and pkgbuild::has_build_tools() does not find Rtools.
    If you get the one on CRAN, it opens a box where you can choose where to install Rtools (by default C:/Rtools) - I do not know why the two installers are different.

  • Add to the PATH on the system C:\RBuildTools\3.5\bin & C:\RBuildTools\3.5\mingw_64\bin.

After that in RStudio, when trying to install from source with devtools, RStudio IDE do not find Rtools and open a box to offer to download Rtools, even if I already have it.

Describe the problem in detail

When trying to use any devtools function (i.e load_all) that need Rtools, I get the message to download unless I use first

pkgbuild::find_rtools(debug = TRUE)
#> Scanning R CMD config CC...
#> cc_path: c:/Rtools/mingw_64/bin/gcc 
#> 'c:/Rtools/mingw_64/bin/gcc.exe' does not exist
#> Scanning path...
#> ls: C:\RBuildTools\3.5\bin\ls.exe 
#> gcc_path: C:\RBuildTools\3.5\mingw_64\bin\gcc.exe 
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Version: 3.5 
#> Found compatible gcc on path
#> [1] TRUE

After that, everything works find with devtools.

I think I get the message because .Call("rs_canBuildCpp") returns FALSE. I think this function is not checking the PATH environment variable.

If I uninstall Rtools, get the installer directly from CRAN, double click on it and install Rtools in C:/Rtools, configure PATH with new paths, oddly everything is working now.

  • .Call("rs_canBuildCpp") returns TRUE
  • pkgbuild::has_build_tools() too
  • pkgbuild::find_rtools seems to correctly get the information from R CMD config CC this time
pkgbuild::find_rtools(debug = TRUE)
#> Scanning R CMD config CC...
#> cc_path: c:/Rtools/mingw_64/bin/gcc 
#> install_path: c:/Rtools 
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE

So there seem to be something with the location where RTools is installed... 🤔

Describe the behavior you expected

As I have everything set up in my PATH, I expected to get it to work directly in RStudio without having to call pkgbuild::find_rtools

Session info
devtools::session_info()
#> - Session info ----------------------------------------------------------
#>  setting  value                       
#>  version  R version 3.5.1 (2018-07-02)
#>  os       Windows 10 x64              
#>  system   x86_64, mingw32             
#>  ui       RTerm                       
#>  language (EN)                        
#>  collate  French_France.1252          
#>  ctype    French_France.1252          
#>  tz       Europe/Paris                
#>  date     2018-09-30                  
#> 
#> - Packages --------------------------------------------------------------
#>  package     * version     date       lib source                         
#>  assertthat    0.2.0       2017-04-11 [1] CRAN (R 3.5.1)                 
#>  backports     1.1.2       2017-12-13 [1] CRAN (R 3.5.0)                 
#>  base64enc     0.1-3       2015-07-28 [1] CRAN (R 3.5.0)                 
#>  callr         3.0.0       2018-08-24 [1] CRAN (R 3.5.1)                 
#>  cli           1.0.1       2018-09-25 [1] CRAN (R 3.5.1)                 
#>  crayon        1.3.4       2017-09-16 [1] CRAN (R 3.5.1)                 
#>  desc          1.2.0       2018-09-30 [1] Github (r-lib/desc@0ae0017)    
#>  devtools      1.13.6.9000 2018-09-30 [1] Github (r-lib/devtools@9b4b6e8)
#>  digest        0.6.17      2018-09-12 [1] CRAN (R 3.5.1)                 
#>  evaluate      0.11        2018-07-17 [1] CRAN (R 3.5.1)                 
#>  fs            1.2.6       2018-08-23 [1] CRAN (R 3.5.1)                 
#>  glue          1.3.0       2018-09-16 [1] Github (tidyverse/glue@4e74901)
#>  htmltools     0.3.6       2017-04-28 [1] CRAN (R 3.5.1)                 
#>  knitr         1.20        2018-02-20 [1] CRAN (R 3.5.1)                 
#>  magrittr      1.5         2014-11-22 [1] CRAN (R 3.5.1)                 
#>  memoise       1.1.0       2017-04-21 [1] CRAN (R 3.5.1)                 
#>  pkgbuild      1.0.1.9000  2018-09-30 [1] Github (r-lib/pkgbuild@446d70c)
#>  pkgload       1.0.0       2018-07-07 [1] CRAN (R 3.5.1)                 
#>  prettyunits   1.0.2       2015-07-13 [1] CRAN (R 3.5.1)                 
#>  processx      3.2.0       2018-08-16 [1] CRAN (R 3.5.1)                 
#>  ps            1.1.0       2018-08-10 [1] CRAN (R 3.5.1)                 
#>  R6            2.2.2       2017-06-17 [1] CRAN (R 3.5.1)                 
#>  Rcpp          0.12.18     2018-07-23 [1] CRAN (R 3.5.1)                 
#>  remotes       1.1.1.9000  2018-09-30 [1] Github (r-lib/remotes@42045fc) 
#>  rlang         0.2.2       2018-08-16 [1] CRAN (R 3.5.1)                 
#>  rmarkdown     1.10        2018-06-11 [1] CRAN (R 3.5.1)                 
#>  rprojroot     1.3-2       2018-01-03 [1] CRAN (R 3.5.1)                 
#>  sessioninfo   1.1.0       2018-09-25 [1] CRAN (R 3.5.1)                 
#>  stringi       1.2.4       2018-07-20 [1] CRAN (R 3.5.1)                 
#>  stringr       1.3.1       2018-05-10 [1] CRAN (R 3.5.1)                 
#>  testthat      2.0.0       2017-12-13 [1] CRAN (R 3.5.1)                 
#>  usethis       1.4.0       2018-08-14 [1] CRAN (R 3.5.1)                 
#>  withr         2.1.2       2018-03-15 [1] CRAN (R 3.5.1)                 
#>  yaml          2.2.0       2018-07-25 [1] CRAN (R 3.5.1)                 
#> 
#> [1] C:/Users/chris/Documents/R/win-library/3.5
#> [2] C:/Program Files/R/R-3.5.1/library
@ronblum
Copy link
Contributor

@ronblum ronblum commented Dec 10, 2018

@cderv Thank you for filing this issue. Is it still an issue with the most recent preview release?

@cderv
Copy link
Collaborator Author

@cderv cderv commented Dec 11, 2018

This is still an issue with preview version.
On a fresh install of R, I have on my windows machine

callr::rcmd_safe("config", "CC")$stdout
#> [1] "c:/Rtools/mingw_64/bin/gcc\n"

However, if I used the installer from pkgbuild::has_build_tools, rtools is installed in C:\Rbuildtools. So there is a mismatch between what if offered by RStudio to download, and what R knows. .Call("rs_canBuildCpp") is still FALSE in preview version, and .rs.installBuildTools is called to offer to download Rtools even I have already done it and it is not in the correct location.

When I use pkgbuild::find_rtools or pkgbuild::has_rtools, the correct path to Rtools is found because I set it in the PATH variable, and the BINPREF is set at the correct value. BINPREF is read by R, and everything is ok after that.

I remind that if I use the binary installer I download from CRAN directly,it offers an installation in c:\rtools and everything is fine.

Also, if I am outside of Rstudio where getOption("buildtools.check") == NULL (not defined), everything is ok because pkgbuild::has_rtools is launched and gets correct path.

So, I don't know why

  • on windows R expect Rtools to be in c:\rtools and does not check the PATH by default. It is define in the source I think.
  • .rs.installBuildTools offers to download a binary different from the one in CRAN
  • .Call("rs_canBuildCpp") returns FALSE even if I put the PATH correctly.
    I try to look into Rstudio code source but not easy for me yet.

This is definitely an edge case because I am not sure everyone we'll look into it as I did and there is a quick workaround but this is definitely something strange in behaviour from RStudio.

Also, in addition, remotes::install_cran(..., type = 'source') on windows does not check for build tools before launching utils::install.packages and we get an error if we use the rtools installer from Rstudio that install the rtools binary in c:/Rbuildtools. This is something that can be corrected in pkgbuild if needed.

Let me know how I can help if you want to dig more.

@kevinushey kevinushey added this to the v1.2 milestone Dec 11, 2018
@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 12, 2018

I'm not able to reproduce on my machine.

I have a single installation of Rtools located at C:/RBuildTools/3.5 (as auto-installed by RStudio), and haven't placed Rtools on the PATH:

> writeLines(strsplit(Sys.getenv("PATH"), ";")[[1]])
C:\R\R-3.5.2beta\bin\x64
C:\Program Files (x86)\Parallels\Parallels Tools\Applications
C:\Perl64\site\bin
C:\Perl64\bin
C:\Program Files (x86)\Common Files\Oracle\Java\javapath
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\WINDOWS\System32\WindowsPowerShell\v1.0\
C:\WINDOWS\System32\OpenSSH\
C:\Program Files\Git\cmd
C:\Program Files\Microsoft VS Code\bin
C:\Users\kevin\AppData\Local\Microsoft\WindowsApps
C:\Perl64\bin
C:\R\R-3.5.2beta\bin
C:\Program Files\7-Zip
C:\Program Files\apache-ant-1.10.5\bin
C:\Program Files\CMake\bin
C:\Program Files (x86)\Dr. Memory\bin
C:\Users\kevin\bin
C:\Users\kevin\AppData\Roaming\TinyTeX\bin\win32

on windows R expect Rtools to be in c:\rtools and does not check the PATH by default. It is define in the source I think.

This is the default for R, but RStudio updates the PATH as needed whenever we're about to take an action that will invoke Rtools.

.rs.installBuildTools offers to download a binary different from the one in CRAN

I don't think this is true -- we download Rtools using the user's current repos; e.g. this is where we select a URL:

if (module_context::isRtoolsCompatible(rTools))
{
version = rTools.name();
std::string repos = userSettings().cranMirror().url;
if (repos.empty())
repos = module_context::rstudioCRANReposURL();
url = rTools.url(repos);
break;
}

.Call("rs_canBuildCpp") returns FALSE even if I put the PATH correctly.

RStudio runs the moral equivalent of R CMD SHLIB on a file called test.c containing just the contents void test() {}. If that compilation attempt succeeds, then we conclude that Rtools is set up appropriately on the user's system.


It might be worth asking whether this works for you:

file <- tempfile(fileext = ".c")
writeLines("void test() {}", con = file)
R <- file.path(R.home("bin"), "R")
system2(R, c("CMD", "SHLIB", shQuote(file)))

It would also be worth checking what the output of Sys.which("ls.exe") and Sys.which("gcc.exe") is since RStudio uses that to detect if Rtools is already on the PATH:

.rs.addFunction("isRtoolsOnPath", function()
{
return (nzchar(Sys.which("ls.exe")) && nzchar(Sys.which("gcc.exe")))
})

(IIRC this is what devtools used to do at least; not sure if that also reflects the current state of affairs)

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 12, 2018

Also worth saying that older versions of RStudio actually had an issue where these compilation attempts could fail if R itself was not on the PATH, but that should be fixed in the latest v1.2 builds. But it might be worth checking if ensuring R is also on the PATH makes a difference.

@cderv
Copy link
Collaborator Author

@cderv cderv commented Dec 13, 2018

Thanks.

With Rbuildtools out of my PATH (like you)

Here is the result of my PATH from R

Sys.getenv("PATH")
writeLines(strsplit(Sys.getenv("PATH"), ";")[[1]])
#> C:\Program Files\R\R-3.5.1\bin\x64
#> C:\Program Files (x86)\Intel\iCLS Client\
#> C:\ProgramData\Oracle\Java\javapath
#> C:\Program Files\Intel\iCLS Client\
#> C:\Windows\system32
#> C:\Windows
#> C:\Windows\System32\Wbem
#> C:\Windows\System32\WindowsPowerShell\v1.0\
#> C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
#> C:\WINDOWS\system32
#> C:\WINDOWS
#> C:\WINDOWS\System32\Wbem
#> C:\WINDOWS\System32\WindowsPowerShell\v1.0\
#> C:\ProgramData\chocolatey\bin
#> C:\Program Files\nodejs\
#> C:\Program Files\SourceGear\Common\DiffMerge\
#> C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
#> C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
#> C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
#> C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
#> C:\WINDOWS\System32\OpenSSH\
#> C:\Program Files\Microsoft VS Code\bin
#> C:\Program Files (x86)\GitExtensions\
#> C:\Program Files\Git\cmd
#> C:\Users\chris\AppData\Roaming\TinyTeX\bin\win32

I delete Rbuildtools from my PATH as you did.

By not having Rtools on PATH, I have that

nzchar(Sys.which("ls.exe")) && nzchar(Sys.which("gcc.exe"))
#> FALSE

and

file <- tempfile(fileext = ".c")
writeLines("void test() {}", con = file)
R <- file.path(R.home("bin"), "R")
system2(R, c("CMD", "SHLIB", shQuote(file)))
#> Warning message:
#> In system(cmd) : 'make' not found

With that setup,

  • install.packages("glue", type = "source") is working correctly. No error and Rbuildtools is found.

  • remotes::install_cran("glue", type = "source", force = TRUE) is not (with error Warning in system(cmd) : 'make' not found). remotes uses utils::install.packages here, and not yours from RStudio that seem to work.

  • remotes::install_github("tidyverse/glue", type = "source", force = TRUE) is working. At some point .Call("rs_canBuildCpp") is TRUE here, and at some point pkgbuild::has_rtools() is run, where Rtools is found thanks to registry here

pkgbuild::has_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path:  
#> '.exe' does not exist
#> Scanning path...
#> Scanning registry...
#> Found C:/RBuildTools/3.5 for 3.5 
#> VERSION.txt
#> Rtools version 3.5.0.4
#> [1] TRUE

(I am using last dev version 9ad3c7176 of remote.)

So issue is different, but there is still something off.

With Rbuildtools on PATH

Here is the result of my PATH from R

Sys.getenv("PATH")
writeLines(strsplit(Sys.getenv("PATH"), ";")[[1]])
#> C:\Program Files\R\R-3.5.1\bin\x64
#> C:\Program Files (x86)\Intel\iCLS Client\
#> C:\ProgramData\Oracle\Java\javapath
#> C:\Program Files\Intel\iCLS Client\
#> C:\Windows\system32
#> C:\Windows
#> C:\Windows\System32\Wbem
#> C:\Windows\System32\WindowsPowerShell\v1.0\
#> C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common
#> C:\WINDOWS\system32
#> C:\WINDOWS
#> C:\WINDOWS\System32\Wbem
#> C:\WINDOWS\System32\WindowsPowerShell\v1.0\
#> C:\ProgramData\chocolatey\bin
#> C:\Program Files\nodejs\
#> C:\Program Files\SourceGear\Common\DiffMerge\
#> C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\DAL
#> C:\Program Files\Intel\Intel(R) Management Engine Components\DAL
#> C:\Program Files (x86)\Intel\Intel(R) Management Engine Components\IPT
#> C:\Program Files\Intel\Intel(R) Management Engine Components\IPT
#> C:\WINDOWS\System32\OpenSSH\
#> C:\Program Files\Microsoft VS Code\bin
#> C:\Program Files (x86)\GitExtensions\
#> C:\Program Files\Git\cmd
#> C:\Users\chris\AppData\Roaming\TinyTeX\bin\win32
#> C:\RBuildTools\3.5\bin
#> C:\RBuildTools\3.5\mingw_64\bin

This time

nzchar(Sys.which("ls.exe")) && nzchar(Sys.which("gcc.exe"))
#> TRUE

and this is now an error

file <- tempfile(fileext = ".c")
writeLines("void test() {}", con = file)
R <- file.path(R.home("bin"), "R")
system2(R, c("CMD", "SHLIB", shQuote(file)))
#> c:/Rtools/mingw_64/bin/gcc  -I"C:/PROGRA~1/R/R-3.5.1/include" -DNDEBUG          -O2 -Wall  -std=gnu99 -mtune=generic -c C:\Users\chris\AppData\Local\Temp\RtmpEzOPTn\file20744004747f.c -o C:\Users\chris\AppData\Local\Temp\RtmpEzOPTn\file20744004747f.o
#> sh: c:/Rtools/mingw_64/bin/gcc: No such file or directory
#> make: *** [C:/PROGRA~1/R/R-3.5.1/etc/x64/Makeconf:208: C:\Users\chris\AppData\Local\Temp\RtmpEzOPTn\file20744004747f.o] Error 127

With this setup

> install.packages("glue", type = "source")
Installing package into 'C:/Users/chris/Documents/R/win-library/3.5'
(as 'lib' is unspecified)
trying URL 'https://cloud.r-project.org/src/contrib/glue_1.3.0.tar.gz'
Content type 'application/x-gzip' length 56368 bytes (55 KB)
downloaded 55 KB

Using libraries at paths:
- C:/Users/chris/Documents/R/win-library/3.5
- C:/Program Files/R/R-3.5.1/library
* installing *source* package 'glue' ...
** package 'glue' correctement décompressé et sommes MD5 vérifiées
** libs

*** arch - i386
c:/Rtools/mingw_32/bin/gcc  -I"C:/PROGRA~1/R/R-3.5.1/include" -DNDEBUG          -O3 -Wall  -std=gnu99 -mtune=generic -c glue.c -o glue.o
sh: c:/Rtools/mingw_32/bin/gcc: No such file or directory
make: *** [C:/PROGRA~1/R/R-3.5.1/etc/i386/Makeconf:208: glue.o] Error 127
ERROR: compilation failed for package 'glue'
* removing 'C:/Users/chris/Documents/R/win-library/3.5/glue'
* restoring previous 'C:/Users/chris/Documents/R/win-library/3.5/glue'
In R CMD INSTALL
Warning in install.packages :
  installation of package 'glue' had non-zero exit status

remotes::install_cran("glue", type = "source", force = TRUE) fails with the same error

and remotes::install_github("tidyverse/glue", type = "source", force = TRUE) does not work because RStudio ask me to download Rtools (my initial report beacause .Call("rs_canBuildCpp") is FALSE). If this is skip with options(buildtools.check = NULL), it is working. Rtools is found by pkgbuild::has_rtools(TRUE) not in registry but directly via R CMD config CC

pkgbuild::has_rtools(TRUE)
#> Scanning R CMD config CC...
#> cc_path: C:/RBuildTools/3.5/mingw_64/bin/gcc 
#> install_path: C:/RBuildTools/3.5 
#> VERSION.txt
#> Rtools version 3.5.0.4 
#> Found compatible gcc from R CMD config CC
#> [1] TRUE

Does this help ? Is it only on my computer ?
I tried to be as detailed as I could be.

Nota: About Rtools download

pkgbuild::has_build_tools gets me to download https://cloud.r-project.org/bin/windows/Rtools/Rtools35.exe. This installer will
install in C:/Rbuildtools without asking anything.
If I download manually at the same url, the installer has a GUI and ask me to choose a path for rtools, offering a default of c:/Rtools

This is what strike me... there is a different behavior I don't explain yet. Rtools installer must have a non-interactive install mode.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 13, 2018

Deleted a prior incorrect analysis.

It all comes down to the BINPREF environment variable, which is used by R to figure out the path to the compiler. It needs to be set to the compiler path as e.g.

BINPREF=C:/RBuildTools/3.5/mingw_$(WIN)/bin/

and evidently RStudio does this for you behind the scenes through some APIs, but this step is skipped if it already sees some Rtools utilities on the PATH.

tl;dr: If you want to explicitly set up Rtools, you need to update both the PATH and BINPREF environment variables.

@cderv
Copy link
Collaborator Author

@cderv cderv commented Dec 13, 2018

Ok so this all relies on BINPREF (and BINPFREF64 ?) !

I found CRAN doc page about this

R CMD INSTALL works in Windows to install source packages. No additional tools are needed if the package does not contain compiled code, and install.packages(type="source") will work for such packages (and for those with compiled code if the tools (see The Windows toolset) are on the path, and the variables BINPREF and BINPREF64 are set properly; see the discussion below). We have seen occasional permission problems after unpacking source packages on some systems: these have been circumvented by setting the environment variable R_INSTALL_TAR to ‘tar.exe’.

So either

  1. you install Rtools in c:/rtools because it was build with this option (see r-source)
  2. you install Rtools in another location and in this case c:/Rbuildtools because pkgbuild::has_build_tools force you too, but you have to set all three variables PATH, BINPREF, BINPREF64 to have all install* function works. (I tested it)

Thanks for all this clarification. It was really interesting to dig into that.
I think it really needs more documentation. 😄 I don't know where...

I understand that RStudio hides all that and tries to do all this by itself. RStudio install.packages hook is doing that well if rtools is not in c:/rtools, but it hides that utils::install.packages does not work in that case. remotes use the non hook install.package and does not work in that case.

Do you think maybe something can/should be made to help users ? (but I may be the only one disturbed by that... 🤔 ) At the end, this is not an issue per se but improvement could be good.

Either in remotes, so that it tries to use the rstudio install.packages function and works ?
Or in RStudio that the function that launch the installation of Rtools prints a message to not forget to set the env variables. By the way, I do not explain why the installation for Rtools from RStudio following pkgbuild::has_build_tools does not offers to install in C:/rtools whereas the one by myself on CRAN at the same url. Do you know why ? This is what get me to open the issue.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 14, 2018

I think there's a couple options (not mutually exclusive):

  1. RStudio could consider trying to detect Rtools on startup and just set BINPREF + PATH by default, rather than only when invoking Rtools-using actions internally. This way things would work 'by default', but it's possible we could end up breaking some configurations. I think this is worth considering, though, especially since IIUC this is a new requirement for users (in the past, just updating the PATH was sufficient)

  2. remotes could also update the PATH + BINPREF when taking actions which require Rtools.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 17, 2018

I think we now properly handle this particular case on the RStudio side: if we detect that Rtools is on the PATH but BINPREF is not set, then we still make sure to set BINPREF so that compilation can succeed.

Ironically, you would make your life easier by not trying to put Rtools on the PATH for RStudio here :-)

@cderv
Copy link
Collaborator Author

@cderv cderv commented Dec 17, 2018

Ironically, you would make your life easier by not trying to put Rtools on the PATH for RStudio here :-)

The easier is to install Rtools with admin right, from CRAN website, manually. Using the one I get with pkgbuild::has_build_tools, it installs in a directory that is not c:/rtools expected by R, and I need to put in PATH if I want utils::install.packages to work. Or just set BINPREF maybe, but I need to do something. 🤔
I will try again at work where I don't have admin right so it needs to be set.

How can I test ? With rstudio daily build from today ?

And thanks a lot for your help and investigation !

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 17, 2018

The latest daily build should indeed have the change.

Note that this will only currently fix build actions performed by RStudio; e.g. 'Install and Restart' with Ctrl + Shift + B. Other packages (e.g. pkgbuild) won't work unless PATH + BINPREF are set up as necessary.

@cderv
Copy link
Collaborator Author

@cderv cderv commented Dec 18, 2018

Ok I see. I'll test soon with the IDE and I will also see if I can come up with some ideas for other 📦

Thanks a lot!

@jmcphers
Copy link
Member

@jmcphers jmcphers commented Jan 8, 2019

@cderv We think this is fixed, so we're closing the issue -- please feel free to reopen if it still looks busted on your end!

@kendonB
Copy link

@kendonB kendonB commented Feb 22, 2019

I am still seeing this error on 1.2.1280. Has this fix made it to Preview yet?

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Feb 22, 2019

Yes, it should have been fixed. Can you elaborate on exactly what you're seeing? (the issue has gotten a bit long and difficult to track)

@kendonB
Copy link

@kendonB kendonB commented Feb 22, 2019

I have installed Rtools 3.5 direct from the Rtools website and Rstudio does not detect it. I see:

> Sys.getenv("BINPREF")
[1] ""
> Sys.getenv("PATH")
[1] "C:\\Program Files\\R\\R-3.5.1\\bin\\x64;C:\\Rtools\\bin;otherstuff

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Feb 22, 2019

Rstudio does not detect it

Sorry to be pedantic, but what does this mean? Do you mean that attempts to build packages (e.g. Ctrl + Shift + B) fail? Or that attempts to install packages from source fail? Or something else?

@kendonB
Copy link

@kendonB kendonB commented Feb 22, 2019

Same as in the issue title: Rstudio offers to install Rtools when attempting to install a package from source via install_github

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Feb 22, 2019

Can you also share your session info? Are you using devtools::install_github() or remotes::install_github() directly?

If Ctrl + Shift + B works for R package projects, but devtools::install_github() does not, then it may be a bug on the devtools side.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Feb 22, 2019

Also note that RStudio would normally set BINPREF for you, e.g.

// set environment variables
FilePath gccPath = installPath_.childPath("mingw_$(WIN)/bin");
environmentVars.push_back(
std::make_pair("BINPREF", asRBuildPath(gccPath)));

and it seems to work for me:

> Sys.getenv("BINPREF")
[1] "C:/RBuildTools/3.5/mingw_$(WIN)/bin/"

@kendonB
Copy link

@kendonB kendonB commented Feb 22, 2019

> devtools::session_info()
- Session info -----------------------------------------------------------------------------------------------------------
 setting  value                       
 version  R version 3.5.1 (2018-07-02)
 os       Windows 10 x64              
 system   x86_64, mingw32             
 ui       RStudio                     
 language (EN)                        
 collate  English_United States.1252  
 ctype    English_United States.1252  
 tz       Pacific/Auckland            
 date     2019-02-23                  

- Packages ---------------------------------------------------------------------------------------------------------------
 package     * version    date       lib source                         
 assertthat    0.2.0      2017-04-11 [1] CRAN (R 3.5.1)                 
 backports     1.1.2      2017-12-13 [1] CRAN (R 3.5.0)                 
 callr         2.0.4      2018-05-15 [1] CRAN (R 3.5.1)                 
 cli           1.0.0      2017-11-05 [1] CRAN (R 3.5.1)                 
 crayon        1.3.4      2017-09-16 [1] CRAN (R 3.5.1)                 
 curl          3.2        2018-03-28 [1] CRAN (R 3.5.1)                 
 desc          1.2.0      2018-05-01 [1] CRAN (R 3.5.2)                 
 devtools      2.0.1      2018-10-26 [1] CRAN (R 3.5.2)                 
 digest        0.6.18     2018-10-10 [1] CRAN (R 3.5.1)                 
 fs            1.2.3      2018-06-08 [1] CRAN (R 3.5.1)                 
 glue          1.3.0      2018-07-17 [1] CRAN (R 3.5.1)                 
 magrittr      1.5        2014-11-22 [1] CRAN (R 3.5.1)                 
 memoise       1.1.0      2017-04-21 [1] CRAN (R 3.5.1)                 
 packrat       0.4.9-3    2018-06-01 [1] CRAN (R 3.5.1)                 
 pkgbuild      1.0.2      2018-10-16 [1] CRAN (R 3.5.2)                 
 pkgload       1.0.2      2018-10-29 [1] CRAN (R 3.5.2)                 
 prettyunits   1.0.2      2015-07-13 [1] CRAN (R 3.5.2)                 
 processx      3.2.0.9000 2018-11-14 [1] Github (r-lib/processx@8374340)
 ps            1.2.1      2018-11-06 [1] CRAN (R 3.5.1)                 
 R6            2.3.0      2018-10-04 [1] CRAN (R 3.5.1)                 
 Rcpp          1.0.0      2018-11-07 [1] CRAN (R 3.5.1)                 
 remotes       2.0.2      2018-10-30 [1] CRAN (R 3.5.2)                 
 rlang         0.3.1      2019-01-08 [1] CRAN (R 3.5.2)                 
 rprojroot     1.3-2      2018-01-03 [1] CRAN (R 3.5.1)                 
 rstudioapi    0.7        2017-09-07 [1] CRAN (R 3.5.1)                 
 sessioninfo   1.1.1      2018-11-05 [1] CRAN (R 3.5.2)                 
 stringi       1.1.7      2018-03-12 [1] CRAN (R 3.5.0)                 
 stringr       1.3.1      2018-05-10 [1] CRAN (R 3.5.1)                 
 testthat      2.0.0      2017-12-13 [1] CRAN (R 3.5.1)                 
 usethis       1.4.0      2018-08-14 [1] CRAN (R 3.5.2)                 
 withr         2.1.2      2018-03-15 [1] CRAN (R 3.5.1)                 

[1] C:/Users/kmbel/Documents/R/win-library/3.5
[2] C:/Program Files/R/R-3.5.1/library

Ctrl + Shift + B can see Rtools but still offers to install Rtools after it fails:

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

'"C:\Rtools\bin\ansicon"' is not recognized as an internal or external command,
operable program or batch file.
'"C:\Rtools\bin\ansicon"' is not recognized as an internal or external command,
operable program or batch file.
* installing to library 'C:/Users/kmbel/Documents/R/win-library/3.5'
* installing *source* package 'degreedays' ...
** libs
C:/Rtools/mingw_64/bin/g++  -std=gnu++11 -I"C:/PROGRA~1/R/R-35~1.1/include" -DNDEBUG  -I"C:/Users/kmbel/Documents/R/win-library/3.5/Rcpp/include" -I"C:/Users/kmbel/Documents/R/win-library/3.5/RcppParallel/include"     -DRCPP_PARALLEL_USE_TBB=1   -O2 -Wall  -mtune=generic -c RcppExports.cpp -o RcppExports.o
C:/Rtools/mingw_64/bin/g++ -shared -s -static-libgcc -o degreedays.dll tmp.def RcppExports.o degreedays.o -LC:/Users/kmbel/Documents/R/win-library/3.5/RcppParallel/lib/x64 -ltbb -ltbbmalloc -LC:/PROGRA~1/R/R-35~1.1/bin/x64 -lR
installing to C:/Users/kmbel/Documents/R/win-library/3.5/degreedays/libs/x64
** R
** byte-compile and prepare package for lazy loading
** help
  converting help for package 'degreedays'
    bins_ss                                 html  
    days_in_bin_daily                       html  
    hello                                   html  
    parDotProd                              html  
    parInnProd                              html  
    poly_ss                                 html  
    sin_estimate_NumericVector              html  
    spl1_band_daily                         html  
    spl1_band_ss                            html  
    spl3_band_daily                         html  
    spl3_band_ss                            html  
*** installing help indices
    finding HTML links ... done
** building package indices
** testing if installed package can be loaded
* DONE (degreedays)
In R CMD INSTALL

Exited with status 1.

When you say it works for you, have you installed Rtools yourself before running rstudio?

@kendonB
Copy link

@kendonB kendonB commented Feb 23, 2019

I am even still getting the same behavior after uninstall all of rtools, R, and RStudio, installing R and RStudio fresh, and letting RStudio install its own Rtools.

@blueswimmer
Copy link

@blueswimmer blueswimmer commented Mar 7, 2019

@kendonB Any luck with this issue? I am getting the same behavior too. I'm running on a Windows 10 machine.

@kendonB
Copy link

@kendonB kendonB commented Mar 7, 2019

Still no luck. I have no idea how to fix it. I don't usually use that computer so I haven't tried too hard to fix it

@blueswimmer
Copy link

@blueswimmer blueswimmer commented Mar 7, 2019

I see. This is really frustrating. I feel like I'm close to finding out what's the problem but I'm not sure how to do it. It seems that setting the path for Rtools is only temporary (disappears after I restart R), and I'm trying to find out how to set the path to Rtools permanently.

I'm curious if the computer you're trying to install Rtools on is a institution's machine? As in you don't have full administrative rights to the computer.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Mar 7, 2019

'"C:\Rtools\bin\ansicon"' is not recognized as an internal or external command,
operable program or batch file.
'"C:\Rtools\bin\ansicon"' is not recognized as an internal or external command,
operable program or batch file.

I don't know why R is attempting to run a program called ansicon in your case, but AFAICS that program doesn't exist in Rtools and isn't mentioned in the R sources either.

@blueswimmer does it make a difference if you update the PATH in e.g. ~/.Rprofile? Still, none of this should be necessary.

A reproducible example would be helpful if at all possible.

@Toniiiio
Copy link

@Toniiiio Toniiiio commented Jul 25, 2019

I hope this is the right place to add: I have a similar problem. This thread already helped a lot to narrow it down, but i havent solved it yet.

System:

RStudio Edition : Desktop
RStudio Version : 1.1.453
OS Version : Windows 10 Enterprise
R Version : 3.4.3

Steps to reproduce the problem:

On a windows machine with R 3.5.1,

install Rtools in C:/Program Files/R/Rtools.

Describe the problem in detail:

I add BINPREF, BINPREF64 (and PATH, see section Additional Info), but only nzchar(Sys.which("ls.exe")) is TRUE after setting the variables, nzchar(Sys.which("gcc.exe")) is FALSE, see the code below.

Sys.setenv(BINPREF = "C:\\PROGRA~1\\R\\Rtools\\mingw_64\\bin")
Sys.setenv(BINPREF64 = "C:\\PROGRA~1\\R\\Rtools\\mingw_64\\bin")

file.exists(paste0(Sys.getenv("BINPREF"), "\\gcc.exe"))
TRUE
file.exists(paste0(Sys.getenv("BINPREF64"), "\\gcc.exe"))
TRUE
nzchar(Sys.which("gcc.exe"))
FALSE

Desired behaviour:

I want to install packages from source:

But installing from source fails

installing the source package ‘ellipsis’

trying URL 'https://cran.rstudio.com/src/contrib/ellipsis_0.2.0.1.tar.gz'
Content type 'application/x-gzip' length 7045 bytes
downloaded 7045 bytes

* installing *source* package 'ellipsis' ...
** Paket 'ellipsis' erfolgreich entpackt und MD5 Summen überprüft
** libs
Warnung: Ausführung von Kommando 'make -f "C:/PROGRA~1/R/R-34~1.3/etc/x64/Makeconf" -f "C:/PROGRA~1/R/R-34~1.3/share/make/winshlib.mk" SHLIB="ellipsis.dll" WIN=64 TCLBIN=64 OBJECTS="dots.o init.o"' ergab Status 127
ERROR: compilation failed for package 'ellipsis'

Additional info:

Setting variable for Rtools was also done:

path <- "C:\\PROGRA~1\\R\\Rtools\\bin;C:\\PROGRA~1\\R\\R-3.4.3\\bin\\x64;C:\\Program Files (x86)\\Common Files\\Oracle\\Java\\javapath;C:\\ProgramData\\Oracle\\Java\\javapath;c:\\oracle\\product\\11.2.0\\client_1\\bin;C:\\oracle\\product\\11.2.0\\client_64\\bin;C:\\WINDOWS\\system32;C:\\WINDOWS;C:\\WINDOWS\\System32\\Wbem;C:\\WINDOWS\\System32\\WindowsPowerShell\\v1.0\\;C:\\Program Files (x86)\\Sennheiser\\SoftphoneSDK\\;C:\\Program Files (x86)\\WebEx\\Productivity Tools;C:\\Program Files (x86)\\Enterprise Vault\\EVClient\\;C:\\Program Files\\dotnet\\;C:\\Program Files\\PuTTY\\;C:\\Program Files\\Git\\cmd;C:\\R\\PhantomJS\\phantomjs\\bin\\phantomjs.exe"
Sys.setenv(PATH = path)

R tools can be found:

Find Rtools:
  pkgbuild::find_rtools(debug = TRUE)
Scanning R CMD config CC...
cc_path:  
  '.exe' does not exist
Scanning path...
Scanning registry...
Found C:/Program Files/R/Rtools for 3.4 
Found C:/RBuildTools/3.5 for 3.5 
VERSION.txt
Rtools version 3.5.0.4 
[1] TRUE

I have R installed within the company network, so i cant install / uninstall new versions that easily.
I tried to reproduce the problem with same laptop/OS/R and RStudio version. Problems were the same when i didnt have rtools installed. As soon as i installed it, it works.
I noticed that not the gcc in rtools was referenced but in C:/Perl64/. But im not sure this info gives more insight.

Check that @cderv mentioned:

> .Call("rs_canBuildCpp")
[1] FALSE

and

> file <- normalizePath(tempfile(fileext = ".c"), winslash = "/")
Warning message:
  In normalizePath(path.expand(path), winslash, mustWork) :
  path[1]="C:\Users\XZ49D7~1\AppData\Local\Temp\RtmpIfHTlI\filefe42adb4e5b.c": Das System kann die angegebene Datei nicht finden
> writeLines("void test() {}", con = file)
> R <- file.path(R.home("bin"), "R")
> system2(R, c("CMD", "SHLIB", shQuote(file)))
C:\PROGRA~1\R\Rtools\mingw_64\bingcc  -I"C:/PROGRA~1/R/R-34~1.3/include" -DNDEBUG          -O2 -Wall  -std=gnu99 -mtune=generic -c C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.c -o C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.o
C:PROGRA~1RRtoolsmingw_64bingcc: not found
make: *** [C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.o] Error 127
Warnmeldung:
  Ausführung von Kommando 'make -f "C:/PROGRA~1/R/R-34~1.3/etc/x64/Makeconf" -f "C:/PROGRA~1/R/R-34~1.3/share/make/winshlib.mk" SHLIB="C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.dll" WIN=64 TCLBIN=64 OBJECTS="C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.o"' ergab Status 2 
Warning message:
  running command '"C:/PROGRA~1/R/R-34~1.3/bin/x64/R" CMD SHLIB "C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.c"' had status 1 
> unlink(file)

and

> options(buildtools.check = NULL)
> pkgbuild::has_build_tools(debug = TRUE)
Scanning R CMD config CC...
cc_path: C:PROGRA~1RRtoolsmingw_64bingcc 
'C:PROGRA~1RRtoolsmingw_64bingcc.exe' does not exist
Scanning path...
ls: C:\PROGRA~1\R\Rtools\bin\ls.exe 
gcc_path:  
  VERSION.txt
Rtools version 3.4.0.1964 
Version: 3.4 
Found compatible gcc on path
[1] TRUE

@kedonb check: Other tools installed within Rtools folder.

I checked whether i have other stuff installed / moved in there. Thats not the case.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Jul 25, 2019

The BINPREF variables need to be set using forward slashes (/), and need to include a trailing slash. Installing into a path with space will likely not work.

This line:

C:\PROGRA~1\R\Rtools\mingw_64\bingcc  -I"C:/PROGRA~1/R/R-34~1.3/include" -DNDEBUG          -O2 -Wall  -std=gnu99 -mtune=generic -c C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.c -o C:/Users/XZ49D7~1/AppData/Local/Temp/RtmpIfHTlI/filefe42adb4e5b.o
C:PROGRA~1RRtoolsmingw_64bingcc: not found

makes it clear that the compiler could not be found, because your BINPREF is malformed.

FWIW I believe it is sufficient to set

BINPREF=C:/Rtools/mingw_$(WIN)/bin/

and ignore BINPREF64 (but I could be wrong)

@Toniiiio
Copy link

@Toniiiio Toniiiio commented Jul 26, 2019

Thank you so much for the fast reply!

You are right, i should have taken a closer look at that line. Using forward slashes helped.

In addition i had to clean up the PATH variable. Then it worked again:

Steps to fix my problem were:

Sys.setenv(BINPREF = "C:/PROGRA~1/R/Rtools/mingw_64/bin/")
Sys.setenv(BINPREF64 = "C:/PROGRA~1/R/Rtools/mingw_64/bin/")
Sys.setenv(PATH = "C:/Program Files/R/R-3.4.3/bin/x64/;C:/PROGRA~1/R/Rtools/bin/;C:/PROGRA~1/R/Rtools/mingw_64/bin/;.......")

Edit:
I can also confirm that its works without BINPREF64.

@cderv
Copy link
Collaborator Author

@cderv cderv commented Jul 26, 2019

FWIW I believe it is sufficient to set

BINPREF=C:/Rtools/mingw_$(WIN)/bin/

and ignore BINPREF64 (but I could be wrong)

This is what I have set and I can confirm it works for me.

@AIBio
Copy link

@AIBio AIBio commented Aug 15, 2019

@jmcphers @kevinushey FYI it seems there is still inconsistency between pkgbuild mechanism to find Rtools and RStudio one (see r-lib/pkgbuild#65 (comment))

Deactivating the the check from rstudio with options(buildtools.check = NULL) does the trick to have pkgbuild behave correctly. It seems that sometimes pkgbuild finds rtools when RStudio don't.

I'll try to find time to rework a clean example on a fresh install.
I solved this problem. You can try install packages through devtool in R rather than Rstudio.

@MikaelUmaN
Copy link

@MikaelUmaN MikaelUmaN commented Aug 21, 2019

I have tried setting BINPREF but I still get the same problem.

The only thing that works seems to be setting options(buildtools.check = NULL) .

I have RStudio Version 1.2.1335 ,
Microsoft R Open 3.5.3
RBuildTools installed under C:\RBuildTools

and the BINPREF set with only difference that I point to RBuildTools (because it was installed by RStudio) rather than Rtools.

Will this be fixed? It's a bit annoying.

@mirh
Copy link

@mirh mirh commented Aug 26, 2019

ELI5 why function doAddRtoolsToPathIfNecessary bails out, even though scanForRTools doesn't assure a dime about it?

// ok so scan for R tools
bool usingGcc49 = module_context::usingMingwGcc49();
std::vector<r_util::RToolsInfo> rTools;
error = core::r_util::scanForRTools(usingGcc49, &rTools);
if (error)
{
LOG_ERROR(error);
return false;
}

Also here, R/sh/make/whatever has problems with paths with spaces

std::make_pair("BINPREF", asRBuildPath(gccPath)));

@iuiu34
Copy link

@iuiu34 iuiu34 commented Nov 7, 2019

Same Issue happens again with
RStudio Edition : Desktop
RStudio Version : 1.2.5019
OS Version : Windows 10
R Version : 3.6.1
Rtools : 3.5

BINREF env var & path doesn't fix it

@Joonwook
Copy link

@Joonwook Joonwook commented Nov 10, 2019

I have followed the direction on my personal computer and everything works fine. On the other hand, I installed Rtools on my work computer and everything did not work. After spending some time, I found an antivirus program called cylance is blocking the shell program (i.e., sh.exe) from executing my program. I have requested to whitelist any exe files in RTools.
Below is the code I use for setting up RCpp as suggested by others.
library(inline)
library(Rcpp)
library(RcppArmadillo)
library(devtools)
Sys.setenv(PATH = paste("C:/Rtools/bin","C:/Rtools/mingw_64/bin", Sys.getenv("PATH"), sep=";"))
Sys.setenv(BINPREF = "C:/Rtools/mingw_$(WIN)/bin/")

#Add this line to .Rprofile
Sys.setenv(PATH = paste("C:/Rtools/bin", Sys.getenv("PATH"), sep=";"))

@iuiu34
Copy link

@iuiu34 iuiu34 commented Nov 11, 2019

yep, seems that is the problem.
thx

@adimajo
Copy link

@adimajo adimajo commented Apr 29, 2020

Setting BINPREF worked for me as well.

[rant]
I just wished there were a cleverer solution than "get angry at the computer; google the problem; hope you find this thread; take 1/2 an hour to understand the 3 different ways R/RStudio deals with Rtools; update an ad hoc environment variable"

You should probably either accomodate (i.e. in an easier way) for custom installation locations of Rtools or force the installation path of Rtools (which would be bad IMHO: I got stuck here for the sole reason that I don't have write access to C:/ and since everything else doesn't require the user to have administrative rights...).

All in all, you must also acknowledge that expecting the user to find this thread and update an environment variable is far from a fix worth closing this issue.
[/rant]

Don't take this the wrong way: I'm overall amazed by the capabilities of RStudio and really thankful for the hard work!

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Apr 29, 2020

The issue here, as I understand it...

If Rtools is not on the PATH, then RStudio will attempt to find Rtools and set it up appropriately. This includes setting BINPREF, as per:

// set environment variables
FilePath gccPath = installPath_.childPath("mingw_$(WIN)/bin");
environmentVars.push_back(
std::make_pair("BINPREF", asRBuildPath(gccPath)));

If Rtools is on the PATH, then RStudio assumes that it has already been set up appropriately, and doesn't take any further action (ignoring BINPREF). This was probably the wrong action to take and we could've just automatically set BINPREF based on the Rtools install location.

I don't know if this requirement (setting BINPREF) was documented for older versions of Rtools, but at least things will be simpler in Rtools40 + R 4.0.0...

@carinaufer
Copy link

@carinaufer carinaufer commented Jun 4, 2020

Hi,
I am relatively green when it comes to deeper software/hardware stuff and I do not understand everything that was written here and what this means.
I encounter the same problem as written above. I executed some of the commands written in this post and I think it messed it up even more because I did not understand their meaning.

I also don't know if I'm incorporating the code in the well-formatted manner as I see it in the other posts. However this is what I can report:

`pkgbuild::find_rtools(debug = TRUE)
Scanning R CMD config CC...
cc_path:
'' does not exist
Scanning path...
Scanning registry...
Found C:/Rtools for 3.5
VERSION.txt
Rtools version 3.5.0.4
[1] TRUE

Sys.which('gcc.exe')
gcc.exe
""
file.exists(paste0(Sys.getenv("BINPREF"), "\gcc.exe"))
[1] FALSE
`
This somehow seems to be the problem I guess. When I look into the folder manually C:/R/Rtools/mingw_64/bin/ I can however find the gcc file.

I also tried to update R, RStudio and tried the old Rtools version (3..) and also Rtools 4.0.0.

I tried setting PATH and BINPREF but I still encounter the problem.
With all this manual setting of the paths and preferences I am also wondering if this could now additionally cause some problems when not setting back to what it was before and also with trying different Rtool versions (especially since the newest version 4 seems to be considerably different). What is the best way to go forward here?

Best,
Carina

@Toniiiio
Copy link

@Toniiiio Toniiiio commented Jun 4, 2020

What is the result of Sys.getenv("BINPREF") and Sys.getenv("PATH") for you?

Note that the check: file.exists(paste0(Sys.getenv("BINPREF"), "\gcc.exe")) should be file.exists(paste0(Sys.getenv("BINPREF"), "gcc.exe")) as BINPREF should be C:/R/Rtools/mingw_$(WIN)/bin/ for you. Note the trailing forward slash at the end, so no need for the backslash.

@carinaufer
Copy link

@carinaufer carinaufer commented Jun 5, 2020

Thanks for your answer. I made it work by copying the gcc file in the usr folder because when I changed the BINPREF to the folder with the gcc file (i.e. C:/R/Rtools/mingw_$(WIN)/bin/) other errors occurred, for example the ls file was not found anymore because this is in the usr folder.
I think this might be due to the different folder structure introduced in Rtools 4.0, but that's just a guess.

@AntonOrnatskyi
Copy link

@AntonOrnatskyi AntonOrnatskyi commented Aug 11, 2020

After I install Rtools4 i see folder names as mingw32, mingw64, not mingw_32, mingw_64 where shell try to find it.

@sheilaabad
Copy link

@sheilaabad sheilaabad commented Sep 4, 2020

There is a new set of instructions for RTools40 on Windows (released April 2020)

https://cran.r-project.org/bin/windows/Rtools/

@sheilaabad
Copy link

@sheilaabad sheilaabad commented Sep 4, 2020

When I run
library(caret)

The result is
Loading required package: ggplot2
Error: package or namespace load failed for ‘ggplot2’ in loadNamespace(j <- i[[1L]], c(lib.loc, .libPaths()), versionCheck = vI[[j]]):
there is no package called ‘vctrs’
Error: package ‘ggplot2’ could not be loaded

I've tried the instructions on the URL https://cran.r-project.org/bin/windows/Rtools/

But I still get the same error

@adimajo
Copy link

@adimajo adimajo commented Sep 4, 2020

@justicesuker
Copy link

@justicesuker justicesuker commented Dec 2, 2021

Hello, guys. I ran into similar problem today and finally figured out the solution. The solution worked for me is from user RolandASc on this thread: https://stackoverflow.com/questions/33103203/rtools-is-not-being-detected-from-rstudio

I manully modified the Makeconf file in my installed R path. e.g. .../R-3.5.1/etc/x64.

I changed from

BINPREF ?= c:/Rtools/mingw_64/bin/

to:

BINPREF ?= C:/rtools40/mingw64/bin/

which is the place where I have installed my Rtools. In this way, RStudio recognizes rtools automatically.

@kevinushey
Copy link
Contributor

@kevinushey kevinushey commented Dec 2, 2021

The problem with that solution is that R 3.5.1 wasn't built with the rtools40 toolchain. Older versions of Rtools are available at https://cran.r-project.org/bin/windows/Rtools/history.html; you'd want to use Rtools35.exe:

https://cran.r-project.org/bin/windows/Rtools/Rtools35.exe

@justicesuker
Copy link

@justicesuker justicesuker commented Dec 6, 2021

I see. Thanks for your kind reply!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests