OHDSI Home | Forums | Wiki | Github

Issues Installing Achilles in R Windows 10


(Alan Fisher) #1

I have been unable to install Achilles in my Environment in AWS. The following errors occur:
** building package indices
** installing vignettes
‘RunningAchilles.Rmd’ using ‘UTF-8’
** testing if installed package can be loaded from temporary location
*** arch - i386
Error: package or namespace load failed for ‘SqlRender’:
.onLoad failed in loadNamespace() for ‘rJava’, details:
call: inDL(x, as.logical(local), as.logical(now), …)
error: unable to load shared object ‘C:/Users/afisher/Documents/R/win-library/4.0/rJava/libs/i386/rJava.dll’:
LoadLibrary failure: %1 is not a valid Win32 application.

Error : package ‘SqlRender’ could not be loaded
Error: loading failed
Execution halted
*** arch - x64
ERROR: loading failed for ‘i386’

  • removing ‘C:/Users/afisher/Documents/R/win-library/4.0/Achilles’
    Error: Failed to install ‘Achilles’ from GitHub:
    (converted from warning) installation of package ‘C:/Users/afisher/AppData/Local/Temp/RtmpGuxuoZ/file5b34209046fe/Achilles_1.6.3.tar.gz’ had non-zero exit status

install_github(“OHDSI/SqlRender”)
Downloading GitHub repo OHDSI/SqlRender@master
√ checking for file ‘C:\Users\afisher\AppData\Local\Temp\RtmpGuxuoZ\remotes5b34362f7096\OHDSI-SqlRender-1de08b0/DESCRIPTION’ (515ms)

  • preparing ‘SqlRender’: (766ms)
    √ checking DESCRIPTION meta-information …
  • checking for LF line-endings in source and make files and shell scripts (504ms)
  • checking for empty or unneeded directories
  • building ‘SqlRender_1.6.6.tar.gz’

Error: Failed to install ‘SqlRender’ from GitHub:
(converted from warning) package ‘SqlRender’ is in use and will not be installed

install_github(“OHDSI/SqlRender@release”)
Error in parse_repo_spec(repo) :
Invalid git repo specification: ‘OHDSI/SqlRender@release

Here is my R version output

R.Version()
$platform
[1] “x86_64-w64-mingw32”

$arch
[1] “x86_64”

$os
[1] “mingw32”

$system
[1] “x86_64, mingw32”

$status
[1] “”

$major
[1] “4”

$minor
[1] “0.1”

$year
[1] “2020”

$month
[1] “06”

$day
[1] “06”

$svn rev
[1] “78648”

$language
[1] “R”

$version.string
[1] “R version 4.0.1 (2020-06-06)”

$nickname
[1] “See Things Now”

Environment Variables:
image

install statements:
library(devtools)
library(rJava)
install_github(“ohdsi/DatabaseConnector”)
install_github(“ohdsi/SqlRender”)
install_github(“ohdsi/Achilles”)


(Adam Black) #2

Try setting the JAVA_HOME environment variable to the empty string or just deleting. I think when using rJava with 64 bit R JAVA_HOME should not be set. Then reinstall rJava.

Sys.setenv(JAVA_HOME = "")
install.packages("rJava")

I’m working on a package to check prerequisites for the OHDSI R packages and hopefully make troubleshooting installation issues a bit easier.

devtools::install_github("ablack3/HadesPrerequisites")
library(HadesPrerequisites)

Installing and loading this package will run some checks. If you decide to try it let me know how it goes!


(Kristin Kostka, MPH) #3

DatabaseConnector and SqlRender are now part of CRAN.

This install statement is probably causing you some issues:

Try using:

install.packages("DatabaseConnector")
install.packages("SqlRender")

If you have issues with multi-arch or locked directories on your GitHub installs, you can add a statement like this:

install.github("ohdsi/Achilles", INSTALL_opts = c('--no-multiarch', '--no-lock'))

You can use also use a similar syntax in install.packages:

install.packages("DatabaseConnector", INSTALL_opts = c('--no-multiarch', '--no-lock'))

cc: @Ajit_Londhe – we should update the documentation to reflect the CRAN migration.


(Ajit Londhe) #4

Hmm. In my experience, I haven’t seen installing from github over CRAN be an issue (just more unwieldy in terms of command syntax). I think here it’s the use of 32 bit architecture.

Personally, I would re-install R and only install the 64 bit version. That way, all packages you install after will just use 64 bit. There really isn’t any need for 32 bit. This is also recommended in the Book of OHDSI:


(Kristin Kostka, MPH) #5

Unfortunately, this happens more often than you think. It may not be in @zuvis’s control. Some machines default to multi-arch for no explainable reason. (@cukarthik has had a lot of trouble with this :wink: )

I would suggest following @Adam_Black’s advice on how to point your rJava to the right place and adding the no multi-arch statements to the install opts. This should resolve it.


(Adam Black) #6

I’m getting the same error when trying to install OHDSI packages relying on rJava on Windows 10. I have only the 64 bit version of R installed, both 32 and 64 bit versions of Java installed. rJava is installed an sucessfully loads when I run library(rJava). However when rJava is loaded during the installation process it fails with
error: unable to load shared object ‘C:/…rJava.dll’
It is very perplexing because it means that loading rJava during OHDSI package installation is somehow different from loading rJava during an interactive R session. Is reducing our dependence on the rJava package such a radical idea? :slight_smile:


(Ajit Londhe) #7

It is radical because many of the analytic packages are Java libraries with R wrappers. This is intentional, as it allows re-use between R packages and with WebAPI.

In terms of the error you’re seeing, is your JAVA_HOME environment variable pointing to the 64 bit folder?


(Adam Black) #8

That makes sense. I just find I have a lot of trouble with rJava that is hard to figure out. Yesterday I tried setting JAVA_HOME to the 64 bit JDK location as well as removing the JAVA_HOME environment variable all together restarting my computer after each change. In both cases rJava would load successfully when calling library(rJava) in a new R session but OHDSI packages relying on rJava would not install due to the error: unable to load shared object ‘C:/…rJava.dll’
This morning the error is gone! Nothing has changed that I’m aware of. I think the problem is having 32 bit Java installed at all. For some reason rJava was picking that up during package installation.


(Ajit Londhe) #9

Yeah, I think you’re right. Having both versions of Java was causing confusion for R when installing packages.

I’ve faced this before in a Linux based system, so I used the which java command to select the one I wanted. Then, I ran a command, R CMD javareconf, that can be used to resolve rJava issues. It basically refreshes the Java setup for the R installation. It can highlight issues in the Java setup.

I think these steps could be done in Windows as well (?)


t