I am using latest R, RStudio and Rtools.
-- I have updated the environment variables. Now I can call gcc, or R from command line.
While I was trying to publish an app from the RStudio, I get the following error,
Preparing to deploy application...DONE Uploading bundle for
application: 64015...Error:
* Application depends on package "Rtools" but it is not installed. Please resolve before continuing. Execution halted
-- I have tried this,On Console,
> find_rtools(T)
Scanning path...
ls : D:\Rtools\bin\ls.exe
gcc: D:\Rtools\GCC-46~1.3\bin\gcc.exe
VERSION.txt
Rtools version 3.3.0.1959
Version: 3.3
[1] TRUE
So, Rtools seems basically there!
-- I have checked environment variables, those are OK, as I also mentioned R and gcc can be started from command line
Yet, I tried to install and check from within RStudio using installr package, it says,
> install.Rtools()
No need to install Rtools - You've got the relevant version of Rtools installed
>
-- This is not a possible duplication of this, Rtools not being detected by R
I have tried all these. Did not work.
Please suggest a solution. Thank you very much for your time.
I have no idea why RStudio has such kind of problems from time to time but there is a manual work-around described here:
https://github.com/rwinlib/r-base/wiki/Testing-Packages-with-Experimental-R-Devel-Build-for-Windows
Basically you have to set two environment variables to point to the correct installation path of Rtools:
Sys.setenv(PATH = paste("C:/Rtools/bin", Sys.getenv("PATH"), sep=";"))
Sys.setenv(BINPREF = "C:/Rtools/mingw_$(WIN)/bin/")
To avoid losing this change after restarting RStudio you could modify your (Windows) environment variables instead or add the following rows to your .Renviron file that is executed at each startup of R.
BTW: The $(WIN) part is no typo but required so that R can inject "32" or "64" depending on the R version you are using (32 or 64 bit).
Edit 1: See also this r-bloggers article published recently: https://www.r-bloggers.com/quirks-about-running-rcpp-on-windows-through-rstudio/
Note that there are new potential kinds of problems (from R 3.3 onwards), since R (not RStudio, but R) adds a BINPREF variable and modifies the Path variable by default, see the Renviron.site file for the latter, on Windows typically e.g. under C:\Program Files\R\R-3.4.3\etc:
PATH="C:\Rtools\bin;${PATH}"
This might easily conflict for people with a custom path and/or multiple versions of Rtools installed, so I have commented this out with a #.
For the BINPREF problem, see the Makeconf file, e.g. under C:\Program Files\R\R-3.4.3\etc\x64:
BINPREF ?= c:/Rtools/mingw_64/bin/
I have then modified this to c:/Rtools34/mingw_64/bin/, which is where I have installed my Rtools34.
You can do the same for the Makeconf file under the 32-bit arch. sub-directory.
Via R CMD check not looking for gcc in Rtools directory:
R uses a BINPREF variable to locate certain executables, including components of RTools.
BINPREF can be set in a number of places. In my case, it was set in C:/Users/MYUSERNAME/Documents/.R/Makevars. Deleting the contents of this file removed a link to a previous, and since deleted, installation of RTools.
It is also worth checking the file $RPATH/etc/i386/Makeconf (swap i386 for x64 if you have a 64-bit installation), which will be re-created with each new installation of R. Note the line
BINPREF ?= c:/Rtools/mingw_32/bin/, which (via the ?= operator) will set the value of BINPREF if it is not already set, as it was in the Makevars file mentioned above.
A temporary fix is to replace BINPREF ?= with BINPREF =,
but as the Makeconf file is overwritten when R is updated, you'll have to remember to do this each time. Better to edit, or delete, the Makevars file for a permanent change.
After searching a lot solutions, finally I delete .Renviron file in C:\Users\My name\Documents. Then rtools40 works.
Related
For many R packages I try to install (on my Windows 10 machine), I get a warning:
> install.packages('rstan')
WARNING: Rtools is required to build R packages but is not currently installed. Please download and install the appropriate version of Rtools before proceeding:
I thought this was just an erroneous error message since the installation seemed to proceed anyway, but recently I tried to install a package (rstan) and found it completely nonfunctional. My hunch is that since rstan relies completely on compiling code with rcpp, maybe I only got away with the previous packages because I wasn't using the functions in them that relied on Rtools.
I reinstalled Rtools 4.0, and devtools::find_rtools() returns TRUE. But when I run Sys.getenv()['PATH'] there is no Rtools on the path. There isn't a place in the installation process to tell it I want Rtools on the path either, so these instructions don't help - the menus they refer to don't exist for me. So I thought this might be an issue where the new Rtools 4.0 doesn't put itself on the system path. But the problem persisted even after I directly edited the Windows path environment variables (both system and user versions) to include the path given to me by pkgbuild::rtools_path() (C:\rtools40\usr\bin, a path which both exists and appears to be correct).
This doesn't seem to be the same problem as Rtools 4.0 (Rstudio falsely claims it was deleted), since there are no claims Rtools was deleted. It's also not the same as Rtools not being detected by R as far as I can tell: I'm not leaving any features out of my Rtools installation - I'm not even getting the option to in my install wizard.
Would appreciate any advice or recommendations.
Rtools40 requires that you add its bin directory to your PATH variable. The full instructions are here.
You can update your ~/.Renviron file with any of the following methods:
You can do that manually by opening ~/.Renviron and putting the following in it:
PATH="${RTOOLS40_HOME}\usr\bin;${PATH}"
You can also use R (Gui or RStudio or Shell) with the following:
writeLines(
'PATH="${RTOOLS40_HOME}\\usr\\bin;${PATH}"',
con = file("~/.Renviron", open = "a")
)
Both of these methods require a restart of R.
I recently installed R 4.0.0. Along with it, I also installed Rtools40. The CRAN website said I also need to specify path for Rtools make file in the .Renviron file. But when I created the .Renviron file, I cannot use stats package. If .Renviron file exists, it gives error that some shared dll file is missing. And if I delete the .Renviron file, this error goes away, but I cannot compile packages using Rtools40. How can I configure this .Renviron file so that I can also use both - Rtools40 and stats package?
My Rtools make file is in C:/(MyUserName)/Rtools40/usr/bin folder. This same folder also contains the bash file, which came with Rtools40.
writeLines('PATH="${PATH};${RTOOLS40_HOME}\\usr\\bin"', con = "~/.Renviron")
I had the same problem. I was following the Rtools40 download instructions, and instead of adding Rtools to the beginning of the path, adding it to the end fixed it.
I have been always using a folder "C:\s" to deploy the always changing versions of R related software friends. I recently installed Rtools40 to "C:\s\rtools40" and linking it with my R-4.0-1 was straightforward to me. I just went to "C:\s\R-4.0.1\etc\x64", edited the "Makeconf" file using WordPad, and replaced the line
RTOOLS40_HOME ?= c:/rtools40
With
RTOOLS40_HOME ?= c:/s/rtools40
Then I did the same for "C:\s\R-4.0.1\etc\x32". After these, I installed a package using RStudio (running install.packages("jsonlite", type = "source") in the R-4.0.1 console), and no warning related to Rtools was displayed in the console. I hope this works well in your machine.
I have been trying to install R packages directly from the terminal but I am struggling much more than setting up the libraries I want in Windows. Sometimes it works if I install every single dependency for more complex packages by downloading them from CRAN and placing them in the R folder.
I appreciate this is not efficient but the recurrent error if I run R within the terminal while installing some of the packages is the following:
** libs
Error in if (nzchar(SHLIB_LIBADD)) SHLIB_LIBADD else character() :
argument is of length zero
* removing ‘/anaconda3/lib/R/library/<package name>’
[...]
In install.packages("<package name>") :
installation of package ‘fpc’ had non-zero exit status
I have been looking across many forums but the only solution I found so far is to install single dependencies manually by downloading them and dropping them in the master R folder. It is taking way longer than expected.
Any suggestion will be appreciated. Thanks
in my case (centos 7):
/home/xilab/miniconda3/lib/R/etc/Makeconf is a empty file!
find ~ -name Makeconf
/home/xilab/miniconda3/pkgs/r-base-3.6.1-hce969dd_0/lib/R/etc/Makeconf
/home/xilab/miniconda3/pkgs/r-base-3.6.1-h8900bf8_2/lib/R/etc/Makeconf
/home/xilab/miniconda3/envs/python2.7/lib/R/etc/Makeconf
/home/xilab/miniconda3/lib/R/etc/Makeconf
/home/xilab/miniconda3/pkgs/r-base-3.6.1-hce969dd_0/lib/R/etc/Makeconf is not empty,so:
mv /home/xilab/miniconda3/lib/R/etc/Makeconf /home/xilab/miniconda3/lib/R/etc/Makeconf.backup
cp /home/xilab/miniconda3/pkgs/r-base-3.6.1-hce969dd_0/lib/R/etc/Makeconf /home/xilab/miniconda3/lib/R/etc/Makeconf
problem solved!
I have seen this problem in conda version of R where /yours/anaconda/environment/lib/R/etc/ has a file Makeconf.mro.original together with an empty Makeconf file. This should not be intended.
During installation of some packages R checks what is within this Makeconf file, one such check is for SHLIB_LIBADD.
I just backed up the empty (or whatever) Makeconf file. Then copied Makeconf.mro.original to Makeconf.
This solved my case.
EDIT:
Recently I saw in centos-machine that Makeconf.mro.original file is not made after install.packages("name of library") failed. There is no easy solution for this.
In my case R installation was inside a conda environment. So, I created a new conda environment with R installation. The fresh installation has a Makeconf file in etc directory. So, I copied the Makeconf file from fresh R to my previously working R's etc directory.
It may be better to keep a backup copy of Makeconf from etc to a Makeconf.bak for future problems, in your working R etc directory.
I hope this helps for some cases.
I had this problem when trying to run install.packages("RPostgres") in a conda-installed version of R . The solution was to use conda as the package manager instead of R's install.packages function. That meant running these commands at a normal system command prompt (not in R):
conda search -c conda-forge RPostgres
# shows various versions of r-rpostgres
conda install -c conda-forge r-rpostgres
Periodically – I think whenever I update R – I have problems installing packages from source on my 64-bit Windows machine.
Today I'm trying to install a package using devtools::install_github(). The installation proceeded fine on my laptop, but my not on my desktop, which can install the package under *** arch - i386, but under *** arch - x64, which reports the error message
C:/PROGRA~1/R/R-34~1.4/bin/x64/R.dll: file not recognized: File format not recognized
The command that caused the error is
C:/Rtools/mingw_32/bin/g++ -shared -s -static-libgcc -o PACKAGENAME.dll [...]
I believe that the error is arising because R is using mingw_32 to attempt to compile a 64-bit package. The question is, where can I tell R to use mingw_64? I've already checked all the places that I can recall:
R-3.4.4/etc/x64/Makeconf states
BINPREF ?= c:/Rtools/mingw_64/bin/
My system PATH (verified from within R using Sys.getenv('PATH')) includes mingw_64 ahead of mingw_32.
R must be looking somewhere else to decide which compiler to use... but where?
Via R CMD check not looking for gcc in Rtools directory:
R was looking in C:/Users/MYUSERNAME/Documents/.R/Makevars for the value of BINPREF. Deleting the contents of this file removed the incorrect location.
$RPATH/etc/i386/Makeconf is re-created with each new installation of R, and contains the line
BINPREF ?= c:/Rtools/mingw_32/bin/.
The ?= operator will set the value of BINPREF if it is not already set, as it was in the Makevars file mentioned above. So replacing ?= with = will work until a new version of R is installed and the Makeconf file is overwritten – updating, or uninstalling, R will not modify the Makevars file in the User directory.
If you start digging from devtools::install_github, it will lead you through the following functions:
devtools::install_github
devtools:::install_remotes
devtools:::try_install_remote
devtools:::install_remote
devtools:::install
devtools:::check_build_tools
devtools:::setup_rtools
devtools:::scan_path_for_rtools
And when you run the following code:
devtools:::scan_path_for_rtools(TRUE)
devtools:::setup_rtools(debug=TRUE)
Most likely, it is saying that Rtools is not currently installed. (Yes, a bit counterintuitive given that you already have it installed in C:/Rtools but maybe not registered in registry)
To fix it, you will need to run (which is in essence the solution in Rtools is not being detected from RStudio)
Sys.setenv(PATH=paste0("C:\\Rtools\\bin;", Sys.getenv("PATH")))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_64/bin", version=3.4), class="rtools"))
devtools:::set_rtools_path(structure(list(path="c:/Rtools/mingw_32/bin", version=3.4), class="rtools"))
Please let me know if this works.
BINPREF ?= c:/Rtools/mingw_64/bin/
remove ? before =
I am trying to do R CMD check before uploading my package to CRAN.
R CMD check --as-cran "my package folder".
However, it spits out this warning:
"checking for unstated dependencies in examples ... OK
WARNING
pdf is needed for checks on size reduction of PDFs"
I searched online but found no clue to solve this problem. This warning does not turn up when I run "R CMD check" only. And my package works with no problem. Could someone please tell me what might be wrong with my package?
qpdf is an external program necessary to reduce the size of pdf, it can be downloaded from the sourceforge site. You can install either the 32 bis or 64 bits version, both are working.
To install it, you download the file, and then copy the folder to your program folder.
Next you need to edit you system path to point to the bin folder by adding 'C:\Program Files\qpdf-version_numer\bin'. In a command batch (cmd) type qpdf to see if that has been set correctly, you should get the message
qpdf: an input file name is required
Usage: qpdf [options] infile outfile
For detailed help, run qpdf --help
Once this is done, the warning should be removed from your R CMD check
To add to Cedric's answer:
If you are running the 32-bit version of R, it is important that you download the 32-bit version of qpdf, which is the version linked from the SourceForge homepage. If you are running a 64-bit installation of R, you will need to do a bit of digging to locate the 64-bit version of qpdf, which is buried a little more deeply (version 7.0 is listed here).
Once you have extracted the zipped qpdf directory to your hard disk, perhaps under C:\Program Files, added C:\Program Files\qpdf-version_no\bin to your system PATH under the environment variables, and re-launched R so it picks up the new PATH, you need to convince Windows that pqdf is safe to run.
Navigate to C:\Program Files\qpdf-version_numer\bin and execute qpdf.exe (by double-clicking). Windows 10 throws up a security warning as it's an unrecognized executable file. You'll need to use the more options link to find the button to run the program. Once you've done this, Windows will recognize the file as safe to run and allow other programs, including R, to use it.