Hi,
Context
I am maintaining an R package for multiple imputation which has a secondary Bayesian implementation which we have implemented in Stan. As the intended / “main” way of using the package is to not use the Bayesian implementation (and because we didn’t want to have Stan on our imports list nor compile the model at install time in order to reduce the friction for users installing the package) we have Stan on our suggests list. Thus in order to use the model we compile and sample from it on the fly caching the model in the users current R temp directory
Problem
We are getting two R CMD check failures related to rstan on 2 specific machines
── Error ('test-draws.R:144:9'): bayes ─────────────────────────────────────────
Error in `fit_mcmc(designmat = model_df_scaled[, -1, drop = FALSE], outcome = model_df_scaled[,
1, drop = TRUE], group = data2[[vars$group]], visit = data2[[vars$visit]],
subjid = data2[[vars$subjid]], method = method, quiet = quiet)`: unable to load shared object '/tmp/RtmpBEQrRR/working_dir/RtmpXQXMbb/file11f85b3c2c931e.so':
libunwind.so.1: cannot open shared object file: No such file or directory
Error in `stanc(file = file, model_code = model_code, model_name = model_name,
verbose = verbose, obfuscate_model_name = obfuscate_model_name,
allow_undefined = allow_undefined, allow_optimizations = allow_optimizations,
standalone_functions = standalone_functions, use_opencl = use_opencl,
warn_pedantic = warn_pedantic, warn_uninitialized = warn_uninitialized,
isystem = isystem)`: parser failed badly; maybe try installing the V8 package
We have been unable to replicate either of these issues on our local machines nor on CRANs mac builder service and we are a bit of a loss for what could possibly be causing the errors. We were hoping someone here might have some insight or pointers that could help us further diagnose the problem.
Thank you for any help or guidance that you might be able to provide.
For reference we had a similar issue a week or so ago which occured when CRAN removed the g++ libraries from the path on their Clang machine however that appeared to just solve itself once the package was re-tested link