Rstan no longer working

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/': 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:

Here is info about the platform etc:

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/
LAPACK: /software/sse/manual/R/3.6.3/g73/nsc1/lib64/R/lib/

 [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      

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.

You can probably get by temporarily by doing

rstan_options(javascript = FALSE)

if you have the latest rstan, but you are going to have to figure out what it causing v8 to not load before rstan_2.25.x .

That didn’t help unfortunately. I get the same error.

What happens if you just do



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.

Thanks @bgoodri, that explain the mystery.

Is 2.19.3 the latest version without the V8 dependency?



I tried installing the previous version, but I’m not having much luck:

g++: error: /home/x_tomli/R/x86_64-pc-linux-gnu-library/3.6.3/rstan/lib//libStanServices.a: No such file or directory
make: *** [] Error 1
ERROR: compilation failed for package ?rstan?
* removing ?/home/x_tomli/R/x86_64-pc-linux-gnu-library/3.6.3/rstan?

I’ve tried googling the error message, but it didn’t make much wiser. Suggestions?

cmdstanr is another R interface for Stan which might work better in this situation:

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.

Thanks everybody for your help. The cluster administrators installed V8 on nodes, so rstan is now running again.

1 Like

I have the same issue. library(rstan) gives this:

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/': 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/': cannot open shared object file: No such file or directory

Running R 4.0.2.

You need to fix your V8 installation soon but in the meantime you can

remotes::install_github("stan-dev/rstan", ref = "develop", subdir = "rstan/rstan")

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…

No, it will become an actual requirement whereas at the moment you can get away with not having it.

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?

The DESCRIPTION of V8 states

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.

1 Like

Thanks Ben. A last question.

Let’s say I build a packge using rstan, can I adopt, similarly to rstanarm

if so is there any guide? I would like to make as less painful as possible for my users.