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: *** [rstan.so] 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: https://mc-stan.org/cmdstanr/
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.
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/V8.so': libv8.so.3.14.5: cannot open shared object file: No such file or directory
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
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
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
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.
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.
It will be folded into rstantools once V8 is actually required by rstan.
I solved it. The V8 package got installed the first time as root (don’t ask), so V8.so was there, I just didn’t have permissions to see it. I killed the entire directory, reinstalled V8 as me, then both it and rstan start up fine Almost embarrassing, really.