New error: cleanup_makevar(old) : argument "RMU" is missing, with no default

@andrjohns @stevebronder Does this solution people are using result in many people having Stan run a lot slower that it can (e.g., because Makevars had -O3 etc.)? Checking on this because it was just reported again on github and the person solved it using this method.

Is this still an issue with the latest version on github? I merged a PR that should have fixed this

Yeah it will run slower because we are missing -O3.

Probably fixed on github installing from source but there hasn’t been a release in a while so people installing the latest CRAN release are still encountering this.

@stevebronder So I guess the best option for now is encouraging people to keep their makevars but install from github?

Yeah I think so, would it be possible to have a bugfix release of rstan for this?

1 Like

That would be a good idea. @bgoodri?

I guess this is a bit of an old issue - but just confirming that I had this error, and the above fix (file.rename etc…) WORKED for me too.

1 Like

Thanks for letting us know. Glad that fixed it for you.

While that fix will work, your models will run slower (since they’re no longer being optimised by the compiler).

Instead, if you follow the instructions here:

You’ll get the optimisations working. You just need to make sure that you don’t update the withr package after doing so

1 Like

I don’t know why, but my looks like this:

CXX14FLAGS=-O3 -Wno-unused-variable -Wno-unused-function
CXX14 = $(BINPREF)g++ -m$(WIN) -std=c++1y
CXX11FLAGS=-O3 -Wno-unused-variable -Wno-unused-function

Since this configuration worked well in the past, I decided to go back to withr 2.2.0.

@andrjohns @stevebronder @jonah

Ran into this issue onWindows10 install (makevars with RMU mention) when I updated a bunch of packages. After reading this thread, I rolled back my installation of “withr” to version 2.2.0 and the problem went away.
I also tested this on my Ubuntu Linux machine but I could replicate this error. I can confirm that this seems to be specific to Windows as some of you noted.
Do we what is causing the breakdown on Windows if using “withr 2.3.0”?

This is very frustrating to encounter in the work flow, but this forum and folks such as you always save the day - not an exaggeration by any means! Thank you and I pray all of you have a safe and a better 2021 than 2020


Sorry about the added frustration! The RStan changes that relied on withr have been reverted, so the next release won’t have this issue

I’m in this deathloop now. I’ve deleted and reinstalled rtools 3.5. I’ve renamed the I’ve installed withr 2.2.0. I have RStudio 1.3.1073 and R 3.6.3. On Windows 10. I’m trying to run the gqs vignette.

``` r
#> Loading required package: StanHeaders
#> Loading required package: ggplot2
#> rstan (Version 2.21.2, GitRev: 2e1f913d3ca3)
#> For execution on a local, multicore CPU with excess RAM we recommend calling
#> options(mc.cores = parallel::detectCores()).
#> To avoid recompilation of unchanged Stan programs, we recommend calling
#> rstan_options(auto_write = TRUE)
#> Do not specify '-march=native' in 'LOCAL_CPPFLAGS' or a Makevars file

# pkgbuild::rtools_path()
# file.rename("~/.R/", "~/.R/")
# remotes::install_version("withr", "2.2.0")

m <- stan_model(model_code = "parameters {real y;} model {y ~ normal(0,1);}")
#> Error in compileCode(f, code, language = language, verbose = verbose): filee7e450811004.o:filee7e450811004.cpp:(.rdata$_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PS[_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PS]+0x0): first defined hereC:/Users/woodwards/Documents/R/win-library/3.6/rstan/lib/x64/libStanServices.a(stan_fit.o):stan_fit.cpp:(.data$_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2QC[_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2QC]+0x0): multiple definition of `long double boost::math::detail::bessel_j0<long double>(long double)::QC'filee7e450811004.o:filee7e450811004.cpp:(.rdata$_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2QC[_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2QC]+0x0): first defined hereC:/Users/woodwards/Documents/R/win-library/3.6/rstan/lib/x64/libStanServices.a(stan_fit.o):stan_fit.cpp:(.data$_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PC[_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PC]+0x0): multiple definition of `long double boost::math::detail::bessel_j0<long double>(long double)::PC'filee7e450811004.o:filee7e450811004.cpp:(.rdata$_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PC[_ZZN5boost4math6detail9bessel_j0IeEET_S3_E2PC]+0x0): first defined herecollect2.exe: error: ld returned 1 exit status
#> Error in sink(type = "output"): invalid connection

Created on 2021-01-29 by the reprex package (v1.0.0)

Hi Simon,

This error is covered in the Getting Started guide, you just need to reinstall RStan and StanHeaders from source


3 months later, this is still not yet fixed. withr (4.1) is current, but the error message is the same, I have to revert to 2.2.0.

Where should we report this to expedite getting a fix?

There’s an upcoming version of RStan (2.26) that no longer has this issue. If you’d like, you can try the experimental preview, with the caveat that you might run into other bugs:

remove.packages(c("StanHeaders", "rstan"))
install.packages("StanHeaders", repos = c("", getOption("repos")))
install.packages("rstan", repos = c("", getOption("repos")))

Thanks, looks good.

… no more error with withr, but both my packages on CRAN/github (dmenne/gastempt, dmenne/breathteststan) produce hundreds of incomprehensible compile statements now. Waiting for some CRAN release now.

Large output when compiling usually comes from compiler warnings when processing files in the RcppEigen and BH packages. You’ll see the same behaviour when compiling rstan and StanHeaders from source (including the versions on CRAN).

You can instruct the compiler not to issue warnings for these by adding the following lines to your Makevars:

CXX14FLAGS += -Wno-ignored-attributes -Wno-deprecated-declarations -Wno-parentheses
CXX14FLAGS += -Wno-sign-compare -Wno-unused-function -Wno-unused-local-typedefs
CXX14FLAGS += -Wno-unused-but-set-variable -Wno-attributes

Thanks, it’s my default settings even when CRAN mode does not like that. And add -Wno-maybe-uninitialized. Nevertheless, I could not make any sense of the output yet. Deleted the src and any makevars locally, did a rstan_config, no success. Reverting to 2.21.x worked. Still searching, the generated h-files had considerable differences.