I went back to a project I haven’ touched in about a month today and, voila, rstan is no longer working. The only related thing I’ve done on the cluster where I’m working on this is a failed attempt to install rstanarm from github, so I may have done something there.
Here is the the error message I got:
Error: package or namespace load failed for rstan in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/x_tomli/R/x86_64-pc-linux-gnu-library/3.6.3/V8/libs/V8.so':
libv8.so.3: cannot open shared object file: No such file or directory
Execution halted
srun: error: n641: task 0: Exited with exit code 1
I also tried the standard stan example on the log-in node, which caused RStudio to crash. Here is a screen shot of the incident:
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)
Matrix products: default
BLAS: /software/sse/manual/R/3.6.3/g73/nsc1/lib64/R/lib/libRblas.so
LAPACK: /software/sse/manual/R/3.6.3/g73/nsc1/lib64/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=sv_SE.UTF-8 LC_NUMERIC=C LC_TIME=C LC_COLLATE=C LC_MONETARY=C
[6] LC_MESSAGES=C LC_PAPER=C LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=C LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.6.3 tools_3.6.3 yaml_2.2.1
I’ve tried reinstalling rstan, V8 and rcpp. Any suggestions of what else to try? I’ve seen other having problems lately that were solved by upgrading to a newer R, but 3.6.3 is the most recent available version on the cluster on which I’m working.
As it turns out, V8 is only installed on the login-node on the cluster on which I’m running analyses. So doing library(V8) works fine on the login-node but gives the same error as library(rstan) when submitting jobs to computational nodes. What confuses me is that V8 was never installed on the computational nodes, yet rstan ran just fine on July 16. Has something in rstan’s dependency on V8 changed lately? I think I reinstalled rstan in the process of attempting to install rstanarm.
The dependence on the V8 package was added recently, probably after July 16th, but will be needed for the indefinite future. So, I would tell the system administrator to install V8 on the computational nodes.
Rstan has more features, but cmdstanr is probably easier to build and use on a cluster. It doesn’t have everything (in particular if you needed rstanarm on the cluster, cmdstanr doesn’t help), but if you’re just running Stan models this might be easier.
Error: package or namespace load failed for ‘rstan’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/ken/R/x86_64-pc-linux-gnu-library/4.0/V8/libs/V8.so':
libv8.so.3.14.5: cannot open shared object file: No such file or directory
and library(V8) gives almost the same thing:
Error: package or namespace load failed for ‘V8’ in dyn.load(file, DLLpath = DLLpath, ...):
unable to load shared object '/home/ken/R/x86_64-pc-linux-gnu-library/4.0/V8/libs/V8.so':
libv8.so.3.14.5: cannot open shared object file: No such file or directory
I was wondering if the V8 requirement will go away in future releases.
As a personal feedback:
The V8 requirement represents a wall for third party stan based tools (together with the existing Makevars setup), as the tools we build based on stan will not be one-command installable install.packages("my_package_based_on_stan")
This drives non-expert users away, as they have to sort external dependecies, conact IT etc…
However, packages such as rstanarm should not need V8 at runtime. V8 works fine on CRAN, Windows, and Mac. There have been some difficulties on Linux, but it is manageable.
But I’m curious, you guys don’t see it as (quite big) cost for app-production to have such heavy dependencies that cannot be sorted with install.package(…)?
I main the point of R, in my opinion, is that non expert users can operate it thanks to it’s package system.
[EDIT I saw yor reply now] …
So to confirm, V8 can be dealt with R dependency system (not in Linux), without intervention?
V8 engine version 6+ is needed for modern JS and WASM support. On Debian / Ubuntu install either libv8-dev or libnode-dev, on Fedora use v8-devel. The readme has instructions for installing backports on Ubuntu Xenial and Bionic. It is still possible to build this package against the legacy libv8 version 3.14 branch, but these engines only support traditional JavaScript (ES5).
So, in order to parse Stan programs on Linux (Mac / Windows V8 binaries should be fine), the machine needs the V8 shared object and development files. However, that should not be an issue for CRAN packages like rstanarm that come with the C++ code generated by the stanc3 parser (on the maintainer’s machine). It might be more of an issue for GitHub packages, depending on how they work.
But the downsides of requiring V8 to parse Stan programs are a moot point. Requiring the OCaml shared object and header files would be just as bad on Linux, worse on Macs, and basically impossible on Windows.
