Can't make cmdstan 2.18 in Windows


Yes, I can do it tomorrow (european time).

The compiler is MingW-w64 (gcc 5.3?)

There was a find.exe with windows. Before I hacked cmder to use unix style find, but I found m2-findutils which probably means everything can be installed with conda.

Steps with conda:

  1. Download and install miniconda3 x64 (I recommend python3)
  2. Open anaconda prompt (or cmd if miniconda is found in PATH)
  3. Create conda environment
    #optional step - creates "isolated" environment
    conda create -n cmdstan python=3.7
    # activate env - this is needed everytime you 
    # open commandline, unless you skip creating the conda env
    conda activate cmdstan
    conda install make m2w64-toolchain m2-findutils -c msys2
  1. cd to cmdstan folder and use gnumake as make. There is also mingw32-make which came with the toolchain, it works too.
    gnumake build -j4

If needed, edit makefile and add CC=gcc and CXX=g++ (or/and CPP=g++). These might be needed if msvc was installed on your computer, not sure if this is true.


I can confirm that this works. However, I had to do everything in the Anaconda prompt since a lot of paths (e.g. to mingw binaries) are not set otherwise, even if the “normal” Anaconda paths are set.

Also, gnumake does not seem to be installed through the packages. Using mingw32-make, as you noted @ahartikainen, works perfectly fine.

In the Wiki it should maybe also be noted that even the model has to be build from the same prompt, to ensure the same build environment.

EDIT: Using mingw32-make and the anaconda prompt, the only change to the makefiles I had to make was to add CXXFLAGS += -DSTAN_THREADS. Btw, @wds15, does this change have to be made for each sub-repository or is it enough to make it in stan-math?


That seems a bit weird. I recall compiling sundials through MSVC at some point. It might however be more complicated than simply exchanging cc for cl.


In normal cmd you need to activate the environment, even if you use the base

conda env list

# activate your base environment
conda activate base

There are

# msys2

# anaconda channel

# conda-forge channel

Did the find.exe throw spme garbage before compilation (about wrong cygwin stuff)?

This is due to “incompatibility” between m2 and m2w64 packages.


this change only needs to made to whatever repository you use. So if you run a threaded test in stan-math, then do it there. In case you run a threaded cmdstan model, then you only need to edit cmdstan/make/local (but an entry for the nested stan_math won’t hurt nor be useful).


My bad. I had an old version of Anaconda installed. I uninstalled it, installed the newest miniconda and now that part works great. In cmd in any case, not in PowerShell, what I usually use. But I see that is a general conda issue.

If I install everything as you describe above (so not installing gnumake for now) I get some weird error messages when I try to use make

1 [main] make 12488 find_fast_cwd: WARNING: Couldn't compute FAST_CWD pointer.  Please report this problem to
the public mailing list

and then a bunch of complains about not finding /bin/sh. Afterwards it starts compiling though. This makes it necessary to use mingw32-make. I wonder why you install make at all, in the instructions above. You maybe meant to write gnumake?

EDIT: Sometimes I should try stuff on the command line first before writing. So installing the package make from the channel conda-forge gives you gnumake and that works fine as well. So the difference is maybe that in your miniconda you prefer conda-forge over the standard base channel and that is why get gnumake?


Yes, using conda-forge one gets usually more up-to-date packages on windows. It is a python thing.

The error are coming from the find.exe stuff (or atleast I think they are coming from it). Even so, find.exe works.

Maybe instructions should only use mingw32-make.

Btw, on windows one can use also find.exe found in cmder tools, if one uses that, but in that case one must touch PATH.


Good to know! That actually seems to break it again though… During my last test I had only added CXXFLAGS += -DSTAN_THREADS in the stan-math sub-module while compiling from the cmdstan repository. Now that I set the flag in make/local directly in the cmdstan main folder, I get the old behaviour. I compiled cmdstan like @ahartikainen describes, I compiled your example model from above, @wds15, but then it only prints the cmdstan config and exits before sampling.

Did you set the respective compile flags, @ahartikainen?


No, apparently I did not read the instructions.

I edited the makefile and added the CXXFLAGS += -DSTAN_THREADS there.

I need to try local. Did you see that flag added to command when you compiled your model make/local. Are files without a extensions even a thing?


The cmdstan Makefile starts like this

# CmdStan users: if you need to customize make options,
#   you should add variables to a new file called
#   make/local (no file extension)

As far as I can see it the Stan Makefile reads in a file called local in the folder make if it exists. There you can simply add your own modifications. Files without an extension are a big thing once you leave the Windows world ;-)

When you clone a fresh copy of cmdstan the file make/local isn’t there. So I created it and added exactly one line to it


This way it works great on Ubuntu.

On Windows the compilation still seems to work, but not the sampling.

@ahartikainen I really like your way to set up a mingw toolchain though. It’s convenient and fast.


Yes, I meant if they are a thing on Windows.


  1. make build works?

  2. With make/local compiles

  3. You can not compile from the model.exe

  4. Is the bernoulli model working with your current setup?

  5. If you edit Makefile can you sample your model?

And have you cleaned old cpp/exe files before new compilations? (Is there a make command that forces all the steps?)

ps. Are you using the common \ / quirks found on windows? E.g running exe needs \ but commands need /


I guess. Makefile is also one of those.

Yes to 1 and 2. I can compile @wds15’s sample model without a problem. The Bernoulli example compiles and samples as expected.

I cleaned everything with gnumake clean-all . I tried to abide to the Windows \ / quirks. Like gnumake ../model-path/model.exe to build the model. I know that \ makes problems here.

Well… this is black magic, isn’t it? Now it samples :-D I could swear I didn’t do anything different. It is also quite a bit slower as before, which might be expected with the added overhead. So maybe this toolchain really is the way to go. Thanks @ahartikainen


just Windows.

Great that it works!


Well… this isn’t over yet :-D Motivated by the success with @wds15’s test model, I wanted to compile and sample from one of my own models involving ODEs. I did a proper cleanup of old executables and headers and the model builds fine. However, it exits before sampling.

I am quite sure that the model is correct as it compiles and samples with threading support on Ubuntu and a cluster running CentOS.

If I find time soon I’ll try to break it down to a smaller model to isolate the issue a bit. (Or to see that it works. Then the problem is somewhere in the size of my model maybe, we’ll see)


I added the instructions to wiki.

I still need to test if there are some problems on powershell, but cmd should work.

I skipped the anaconda prompt and cmder (optional).

Also we need to test that this really works for all the models.


I’m, trying to do the steps in the guide - but how do I set STAN_NUM_THREADS?

Found a description of make/local in the cmdstan-guide, but can’t find anything on STAN_NUM_THREADS.


It’s an environment variable that you set directly before you start sampling from your model. If you work in cmd you would write


if you want Stan to figure out the best number of threads or


where you are setting an upper limit yourself (even though Stan might end up using less than four threads).

In Powershell you would put the variable into Env, i.e.


Let us know how it goes. As you can read above, it is still a bit troublesome whether or not within-chain-parallelisation works for all models.


Powershell and Conda environments don’t really play well together. This has been an issue since 2014 but never been properly solved by the conda team.


Thank you, @Cyianor. Looks like I get the same result as you - i.e. it just exits when STAN_NUM_THREADS is greater than 1.

Edit: I used the model and data above, and have created the make/local file with CXXFLAGS += -DSTAN_THREADS in the cmdstan-folder. Apart from that followed the instructions here.


Are there any exceptions?

Can you add -fexceptions to make/local

Is there possibility to run with pbr?