Rstudio: RStudio do not find Rtools and offer to install even if already installed
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 andpkgbuild::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")returnsTRUEpkgbuild::has_build_tools()toopkgbuild::find_rtoolsseems to correctly get the information fromR 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
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
cderv
All 53 comments
@cderv Thank you for filing this issue. Is it still an issue with the most recent preview release?
ronblum
on 10 Dec 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:\rtoolsand does not check the PATH by default. It is define in the source I think. .rs.installBuildToolsoffers 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.
cderv
on 11 Dec 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:
.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: https://github.com/rstudio/rstudio/blob/275d6eba762ffa9d79a189033fd47a6f77781f33/src/cpp/session/modules/ModuleTools.R#L85-L88
(IIRC this is what devtools used to do at least; not sure if that also reflects the current state of affairs)
kevinushey
on 12 Dec 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.
kevinushey
on 12 Dec 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).remotesusesutils::install.packageshere, 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 pointpkgbuild::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.
cderv
on 13 Dec 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.
kevinushey
on 13 Dec 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
- you install Rtools in
c:/rtoolsbecause it was build with this option (see r-source) - you install Rtools in another location and in this case
c:/Rbuildtoolsbecausepkgbuild::has_build_toolsforce 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.
cderv
on 13 Dec 2018
I think there's a couple options (not mutually exclusive):
RStudio could consider trying to detect Rtools on startup and just set
BINPREF+PATHby 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 thePATHwas sufficient)remotescould also update thePATH+BINPREFwhen taking actions which require Rtools.
kevinushey
on 14 Dec 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 :-)
kevinushey
on 17 Dec 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 !
cderv
on 18 Dec 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.
kevinushey
on 18 Dec 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!
cderv
on 18 Dec 2018
@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!
jmcphers
on 8 Jan 2019
I am still seeing this error on 1.2.1280. Has this fix made it to Preview yet?
kendonB
on 22 Feb 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)
kevinushey
on 22 Feb 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
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?
kevinushey
on 22 Feb 2019
Same as in the issue title: Rstudio offers to install Rtools when attempting to install a package from source via install_github
kendonB
on 22 Feb 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
on 22 Feb 2019
Also note that RStudio would normally set BINPREF for you, e.g.
and it seems to work for me:
> Sys.getenv("BINPREF")
[1] "C:/RBuildTools/3.5/mingw_$(WIN)/bin/"
> 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
on 22 Feb 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.
kendonB
on 23 Feb 2019
@kendonB Any luck with this issue? I am getting the same behavior too. I'm running on a Windows 10 machine.
blueswimmer
on 7 Mar 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
kendonB
on 7 Mar 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.
blueswimmer
on 7 Mar 2019
'"C:\Rtools\binansicon"' is not recognized as an internal or external command,
operable program or batch file.
'"C:\Rtools\binansicon"' 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.
kevinushey
on 7 Mar 2019
I think I have managed to solve my problem. I was using a machine with no full admin access (institution’s machine) and my R was not installed on the local machine.
I moved them to local machine and same folder where Rtools was installed and it was working on RStudio, for some reason find_rtools() returns TRUE in R Gui but the PATH is different to what’s on RStudio.
blueswimmer
on 8 Mar 2019
I am using a computer with full admin rights. I have the correct rtools bin in both the system and user environment variables. I no longer see the ansicon message after uninstalling and reinstalling everything.
I have tried updating the PATH in .Rprofile and it makes no difference. @kevinushey Can you let us know exactly what gets run (that's relevant to finding RTools) with Ctrl-Shift-B to help narrow down the problem?
kendonB
on 8 Mar 2019
I'm having the same problem as described in the title of this thread. I don't have admin rights as mentioned by some others before. I'm using the RStudio daily build of March 1st on a Win 10 64bit machine. I installed stan following the instructions found on the RStan GitHub. I tried letting RStudio install Rtools (to C:/RBuildTools/3.5/) and checked pkgbuild::has_build_tools(debug = TRUE) which in return triggers the window to install Rtools...
Piranha688
on 8 Mar 2019
@Piranha688 can you
- can you call
.Call("rs_canBuildCpp")in R Console and see if it is FALSE or TRUE - can you run this lines
file <- normalizePath(tempfile(fileext = ".c"), winslash = "/")
writeLines("void test() {}", con = file)
R <- file.path(R.home("bin"), "R")
system2(R, c("CMD", "SHLIB", shQuote(file)))
unlink(file)
and see if it errors or not.
Also, can you try to set options(buildtools.check = NULL) before running pkgbuild::has_build_tools(debug = TRUE) ?
thanks.
_All this is related to the offer to redownload the Rtools installer. This is linked to all the discussion above I had and will allow to check what is your current state to isolate. I suspect a second issue..._ 🤔
cderv
on 9 Mar 2019
> .Call("rs_canBuildCpp")
[1] FALSE
> file <- normalizePath(tempfile(fileext = ".c"), winslash = "/")
Warning message:
In normalizePath(path.expand(path), winslash, mustWork) :
path[1]="C:\Users\kmbel\AppData\Local\Temp\Rtmp0absnh\file59582cca14eb.c": The system cannot find the file specified
> writeLines("void test() {}", con = file)
> R <- file.path(R.home("bin"), "R")
> system2(R, c("CMD", "SHLIB", shQuote(file)))
The system cannot find the path specified.
c:/Rtools/mingw_64/bin/gcc -I"C:/PROGRA~1/R/R-3.5.2/include" -DNDEBUG -O2 -Wall -std=gnu99 -mtune=generic -c C:/Users/kmbel/AppData/Local/Temp/Rtmp0absnh/file59582cca14eb.c -o C:/Users/kmbel/AppData/Local/Temp/Rtmp0absnh/file59582cca14eb.o
sh: c:/Rtools/mingw_64/bin/gcc: No such file or directory
make: *** [C:/PROGRA~1/R/R-3.5.2/etc/x64/Makeconf:208: C:/Users/kmbel/AppData/Local/Temp/Rtmp0absnh/file59582cca14eb.o] Error 127
> unlink(file)
> options(buildtools.check = NULL)
> pkgbuild::has_build_tools(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:
VERSION.txt
Rtools version 3.5.0.4
Version: 3.5
Found compatible gcc on path
[1] TRUE
Hi @cderv, thanks for your suggestions. I went back to this problem this morning and was able to solve it for me. I uninstalled Rtools once again as well as the rstan-package and (!) the rethinking package. I then followed the installation instructions for rstan. Rtools installed as expected and afterwards pkgbuild::has_build_tools(debug = TRUE) came back TRUE. Then I installed rethinking again and now all works fine.
@kendonB do you have the rethinking-package installed?
Piranha688
on 9 Mar 2019
I was able to solve it for me.
I had (long ago) added ansicon to an autorun command that opened whenever cmd.exe ran (see https://nitin09.wordpress.com/2013/11/12/bashrc-in-windows-for-command-line-startup/). This program allowed for the nice colors in tibble to not display as the underlying color codes (in text) when using cmd.exe. I had placed it in RTools/bin and specified the full path in the autorun. I think a reinstall of Rtools changed that path so it started messing things up. I deleted that autorun stuff and now RStudio is working normally.
So, for RStudio, it seems like it offers to install RBuildTools when any error comes up when running the install command. In my case, I believe the package was actually installing correctly as the cmd program pushes past the error.
I would recommend narrowing the test so RStudio only offers to install RBuildTools if it's actually not there in the normal places.
kendonB
on 9 Mar 2019
@jmcphers @kevinushey FYI it seems there is still inconsistency between pkgbuild mechanism to find Rtools and RStudio one (see https://github.com/r-lib/pkgbuild/issues/65#issuecomment-493462282)
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.
cderv
on 18 May 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.
Toniiiio
on 25 Jul 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)
kevinushey
on 25 Jul 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.
Toniiiio
on 26 Jul 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.
cderv
on 26 Jul 2019
@jmcphers @kevinushey FYI it seems there is still inconsistency between
pkgbuildmechanism 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 sometimespkgbuildfinds 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.
AIBio
on 15 Aug 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.
MikaelUmaN
on 21 Aug 2019
ELI5 why function doAddRtoolsToPathIfNecessary bails out, even though scanForRTools doesn't assure a dime about it?
https://github.com/rstudio/rstudio/blob/cf5076a88a219a275a2d128191c12c1f8f4e3890/src/cpp/session/modules/build/SessionBuildEnvironment.cpp#L137-L145
Also here, R/sh/make/whatever has problems with paths with spaces
https://github.com/rstudio/rstudio/blob/cf5076a88a219a275a2d128191c12c1f8f4e3890/src/cpp/core/r_util/RToolsInfo.cpp#L165
mirh
on 26 Aug 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
Iuiu1234
on 7 Nov 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=";"))
Joonwook
on 11 Nov 2019
yep, seems that is the problem.
thx
Iuiu1234
on 11 Nov 2019
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!
adimajo
on 29 Apr 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:
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...
kevinushey
on 29 Apr 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
carinaufer
on 4 Jun 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.
Toniiiio
on 4 Jun 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.
carinaufer
on 5 Jun 2020
After I install Rtools4 i see folder names as mingw32, mingw64, not mingw_32, mingw_64 where shell try to find it.
AntonOrnatskyi
on 11 Aug 2020
There is a new set of instructions for RTools40 on Windows (released April 2020)
sheilaabad
on 4 Sep 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
sheilaabad
on 4 Sep 2020
Got this error yesterday, fixed it by installing vctrs from source
with--no-multiarch option and BINPREF set to the bitness of my R install.
Le ven. 4 sept. 2020 Ã 4:55 AM, sheilaabad notifications@github.com a
écrit :
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 loadedI've tried the instructions on the URL
https://cran.r-project.org/bin/windows/Rtools/But I still get the same error
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/rstudio/rstudio/issues/3563#issuecomment-686870247,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFTXN7XZLPORY5GYDJX4PDDSEBJJNANCNFSM4FYEIADQ
.
adimajo
on 4 Sep 2020
Related issues
curtis999
·
3Comments
garrettgman
·
3Comments
cderv
·
3Comments
Mashin6
·
3Comments
kevinushey
·
3Comments
Most helpful comment
@jmcphers @kevinushey FYI it seems there is still inconsistency between
pkgbuildmechanism to find Rtools and RStudio one (see https://github.com/r-lib/pkgbuild/issues/65#issuecomment-493462282)Deactivating the the check from rstudio with
options(buildtools.check = NULL)does the trick to have pkgbuild behave correctly. It seems that sometimespkgbuildfinds rtools when RStudio don't.I'll try to find time to rework a clean example on a fresh install.