RStan compilation error with R 4.6.1, Rtools45 and rstan 2.39

Hello,

I am having a compilation problem with RStan on Windows and would appreciate your help identifying the cause.

My current setup is:

  • Windows 10 Pro

  • R 4.6.1 (2026-06-24 ucrt)

  • Rtools45

  • GCC 14.3.0

  • rstan 2.39.0.9000 (Stan R-universe)

  • StanHeaders 2.39.1

  • Rcpp 1.1.2

  • RcppEigen 0.3.4.0.2

Rtools itself appears to be configured correctly:

  • Sys.which("g++") points to C:\\rtools45\\...\\g++.exe

  • g++ --version reports GCC 14.3.0

  • pkgbuild::has_build_tools(debug = TRUE) returns TRUE

  • A simple C compilation with pkgbuild succeeds.

  • BINPREF is empty.

I have also checked the system PATH and removed old Rtools paths from the system environment variables to make sure that there are no conflicting older Rtools installations being used.

However, even a minimal RStan model fails during C++ compilation. I completely reinstalled R and the relevant packages and restarted the computer, but the problem persists.

I have also gone through the suggested solutions I found in the RStan/Stan forums for similar Windows compilation errors, including checking the Rtools configuration, removing old Rtools paths, reinstalling RStan/StanHeaders, and creating ~/.R/Makevars.win with the suggested compiler flags. None of these resolved the problem.

The compilation command correctly uses C++17 (g++ -std=gnu++17).

Initially, the error appeared as:

Error in compileCode(f, code, language = language, verbose = verbose):
...
DenseCoeffsBase.h:654:74: warning: ignoring attributes on template argument
'Eigen::internal::packet_traits<double>::type' {aka '__m128d'}
...
make: *** [...Makeconf:304: file....o]
Error in sink(type = "output"): invalid connection

I found a similar RStan issue where the suggested workaround was to create ~/.R/Makevars.win with:

if (!dir.exists("~/.R")) {
  dir.create("~/.R")
}

cat("CPPFLAGS += -w -Wno-misleading-indendation",
    file = "~/.R/Makevars.win",
    append = TRUE)

I tried this workaround as well, but it did not resolve the problem.

After running the compilation with verbose output, I was able to see the actual fatal error. The relevant part is:

file23584c993ef5.cpp:404:0: required from here
404 | &rstan::stan_fit<stan_model, boost::random::mixmax>::call_sampler)
...
C:/Users/Marta/AppData/Local/R/win-library/4.6/rstan/include/rstan/stan_fit.hpp:387: error:
conversion from 'boost::random::ecuyer1988'
{aka 'boost::random::additive_combine_engine<
boost::random::linear_congruential_engine<unsigned int, 40014, 0, 2147483563>,
boost::random::linear_congruential_engine<unsigned int, 40692, 0, 2147483399>
>'}
to non-scalar type 'boost::random::mixmax'
{aka 'boost::random::mixmax_engine<17, 36, 0>'} requested

make: *** [C:/PROGRA~1/R/R-46~1.1/etc/x64/Makeconf:304: file23584c993ef5.o

R then additionally reports:

Error in sink(type = "output"): invalid connection

The sink() error therefore seems to be secondary; the actual compilation failure appears to be the incompatible conversion between boost::random::ecuyer1988 and boost::random::mixmax in rstan/stan_fit.hpp.

The minimal model I am using to reproduce the issue is:

library(rstan)

rstan_options(auto_write = TRUE)
options(mc.cores = 1)

model_code <- "
data {
  int<lower=0> N;
  array[N] real y;
}
parameters {
  real mu;
}
model {
  mu ~ normal(0, 10);
  y ~ normal(mu, 1);
}
"

test_data <- list(
  N = 10,
  y = rnorm(10)
)

test_model <- stan(
  model_code = model_code,
  data = test_data,
  iter = 500,
  chains = 1
)

Could you please advise whether this is a known compatibility issue between the current RStan/StanHeaders/Boost versions and R 4.6.1/GCC 14.3.0, and what the recommended fix would be?

I would particularly like to stay with RStan rather than switch to CmdStanR, since I need to use existing RStan code for a group project.

Thank you very much for your help!

Best,
Marta

Welcome to the Stan forum. Tagging @andrjohns, who knows the most about rstan 2.39.0.9000 (Stan R-universe), but here’s a guess: I think you might have R-universe RStan but StanHeaders from CRAN (2.39.1 was just released, but RStan hasn’t been released yet). Can you try this in order to ensure that both are from R-universe:

remove.packages(c("rstan", "StanHeaders"))
install.packages("rstan", repos = c("https://stan-dev.r-universe.dev", getOption("repos")))
# overwrite StanHeaders with the R-universe build
install.packages("StanHeaders", repos = "https://stan-dev.r-universe.dev")

@andrjohns now that StanHeaders 2.39.1 is on CRAN I think more users might run into this if installing RStan from R-universe. Do we need to add
-DNEW_RSTAN to the dev version on R-universe or something like that?

Thank you so much for your help!

I don’t think the CRAN/R-universe mismatch was the original cause - it may have been something related to Rtools/toolchain. However, while trying to fix the initial problem, I probably ended up installing the packages from different sources, which created the mismatch.

I have now reinstalled both from R-universe, and it is working! Thank you again for a very fast answer!

Great, glad it’s working now!

@andrjohns now that StanHeaders 2.39.1 is on CRAN I think more users might run into this if installing RStan from R-universe. Do we need to add
-DNEW_RSTAN to the dev version on R-universe or something like that?

Ahh I hadn’t thought about that. Yeah I’ll open a PR for that. Once rstan 2.39 is up on CRAN then the -DNEW_RSTAN handling can be removed from both rstan and StanHeaders.

We’ve only got a handful of failures left for rstan, I’ll open PRs for those so we can hopefully get rstan up soon: Reverse Dependencies (test) · andrjohns/rstan@8473a44 · GitHub