Since a few days, the CRAN checks for our bridgesampling package fail selectively on Windows during the tests of the Stan interface. Uwe Ligges has contacted us, asking to fix the issue.
Sadly, I cannot recreate the problems on my machine, only on winbuilder. On my windows machine the code runs without problem inside RStudio when called interactively and also through R CMD check in the windows shell.
The error message is somewhat cryptic (potentially due to the use of testthat) and I paste it below. It looks like it fails during compilation of the model. The line in question (test-stan_bridge_sampler_basic.R:56:5) is:
I am not sure about the best course of action. To me it looks like the only possibility is to deactivate this test for Windows. However, as this is our only test of the stan interface on CRAN I would like to avoid it. Does maybe anyone from the Stan team have an idea?
-- Error (???): stan_bridge_sampler --------------------------------------------
Error: file76c4707f6b2.o:file76c4707f6b2.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D1Ev[_ZN3tbb8internal26task_scheduler_observer_v3D1Ev]+0x14): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'file76c4707f6b2.o:file76c4707f6b2.cpp:(.text$_ZN3tbb8internal26task_scheduler_observer_v3D0Ev[_ZN3tbb8internal26task_scheduler_observer_v3D0Ev]+0x1c): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'file76c4707f6b2.o:file76c4707f6b2.cpp:(.text$_ZN4stan4math16ad_tape_observerD1Ev[_ZN4stan4math16ad_tape_observerD1Ev]+0x15): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'file76c4707f6b2.o:file76c4707f6b2.cpp:(.text$_ZN4stan4math16ad_tape_observerD1Ev[_ZN4stan4math16ad_tape_observerD1Ev]+0x47): undefined reference to `tbb::internal::task_scheduler_observer_v3::observe(bool)'file76c4707f6b2.o:file76c4707f6b2.cpp:(.text$_ZN4stan4math16ad_tape_observerD0Ev[_ZN4stan4math16ad_tape_observerD0Ev]+0x15): more undefined references to `tbb::internal::task_scheduler_observer_v3::observe(bool)' followcollect2.exe: error: ld returned 1 exit status
Backtrace:
x
1. +-base::suppressMessages(...)
2. | \-base::withCallingHandlers(expr, message = function(c) invokeRestart("muffleMessage"))
3. \-rstan::stan_model(model_code = stancodeH0, model_name = "stanmodel")
4. \-rstan:::cxxfunctionplus(...)
5. +-pkgbuild::with_build_tools(...)
6. | \-withr::with_path(rtools_path(), code)
7. | \-base::force(code)
8. \-inline::cxxfunction(...)
9. \-inline:::compileCode(f, code, language = language, verbose = verbose)
-- Error (???): stan_bridge_sampler --------------------------------------------
Error: invalid connection
Backtrace:
x
1. +-base::suppressMessages(...)
2. | \-base::withCallingHandlers(expr, message = function(c) invokeRestart("muffleMessage"))
3. \-rstan::stan_model(model_code = stancodeH0, model_name = "stanmodel")
4. \-rstan:::cxxfunctionplus(...)
5. \-base::sink(type = "output")
After trying a few things out, we can confirm that at least on GitHub workflow windows, the issue happens with current StanHeaders (2.21.0-7) and rstan (2.21.2). The problem even persists if we reinstall all relevant packages from CRAN from source (i.e., RcppEigen, RcppParallel, StanHeaders, and rstan).
If we use both StanHeaders and rstan from https://mc-stan.org/r-packages/ GitHub action runs the checks without any problems on Windows. So it looks like @hsbadr, you are correct in what drives the problem.
To solve this problem on CRAN, we have since resubmitted to CRAN and simply deactivated the checks on Windows. This now works on Windows but fails on Debian CRAN with a new bunch of compiler error messages:
══ Failed tests ════════════════════════════════════════════════════════════════
── Error (test-stan_bridge_sampler_basic.R:57:5): stan_bridge_sampler ──────────
Error: 14 | static void set_zero_all_adjoints() { | ^~~~~~~~~~~~~~~~~~~~~/usr/bin/ld: /home/hornik/lib/R/Library/4.1/x86_64-linux-gnu/rstan/lib//libStanServices.a(stan_fit.o): relocation R_X86_64_PC32 against undefined hidden symbol `_ZTCN5boost10wrapexceptISt14overflow_errorEE0_NS_16exception_detail10clone_implINS3_19error_info_injectorIS1_EEEE' can not be used when making a shared object/usr/bin/ld: final link failed: bad valuecollect2: error: ld returned 1 exit statusmake: *** [/home/hornik/tmp/R/share/make/shlib.mk:10: file7b1473f724f17.so] Error 1
Backtrace:
█
1. ├─base::suppressWarnings(stan_model(model_code = stancodeH0, model_name = "stanmodel")) test-stan_bridge_sampler_basic.R:57:4
2. │ └─base::withCallingHandlers(...)
3. └─rstan::stan_model(model_code = stancodeH0, model_name = "stanmodel")
4. └─rstan:::cxxfunctionplus(...)
5. ├─pkgbuild::with_build_tools(...)
6. └─inline::cxxfunction(...)
7. └─inline:::compileCode(f, code, language = language, verbose = verbose)
── Error (test-stan_bridge_sampler_basic.R:57:5): stan_bridge_sampler ──────────
Error: invalid connection
Backtrace:
█
1. ├─base::suppressWarnings(stan_model(model_code = stancodeH0, model_name = "stanmodel")) test-stan_bridge_sampler_basic.R:57:4
2. │ └─base::withCallingHandlers(...)
3. └─rstan::stan_model(model_code = stancodeH0, model_name = "stanmodel")
4. └─rstan:::cxxfunctionplus(...)
5. └─base::sink(type = "output")
I have the suspicion that suggests that somehow on CRAN Debian there is some incompatibility between RcppParallel, RcppEigen, and rstan, but I am not sure how to navigate this. The current version does not fail on CRAN and none of the changes in the newly submitted version should cause something like this (and also work perfectly on GitHub workflow Debian).
Any ideas what this could be or how we can keep bridgesampling on CRAN with rstan support?
This looks like a boost-RcppEigen-StanHeaders-rstan compatibility issue on this specific machine (i.e., the shared objects have incorrect signatures). This could happen if, for example, if boosts version is incompatible (not supported / older / newer - upgraded or downgraded). The packages need to be reinstalled, in order (boost-RcppEigen-StanHeaders-rstan), to update/link to the current libraries (and headers).
libStanServices.a(stan_fit.o): relocation R_X86_64_PC32 against
undefined hidden symbol `_ZTCN5boost10wrapexceptISt14overflow_errorEE0_NS_16exception_detail10clone_implINS3_19error_info_injectorIS1_EEEE'
Thanks, something like this was also my suspicion. So now I just need to get CRAN to believe me on this and reinstall it in the right order on their machine. Seems like a somewhat impossible task.
I just want to close this topic as solved. Due to another deadline, I could only get back to this last week.
We submitted another unchanged version (only increased the version number) to CRAN last week which also bounced due to the same compiler problem on Debian. We explained the issue to CRAN and after some back and forth and another round of extensive checks on our end, they updated their package installation. We then submitted another unchanged version (again with increased version number, 1.1-2) which was just accepted on CRAN.
The only lingering problem for us is that we had to disable the checks on Windows. We will enable them again once a new rstan version is on CRAN.