nutpie
nutpie copied to clipboard
Test compiling stan model in conda with conda-forge compilers installed
Otherwise it seems this can lead to the stan makefile not recognizing the compiler:
RuntimeError: Command make STAN_THREADS=true STANCFLAGS=--include-paths=. /tmp/tmp9av6ksrm/model_model.so failed with code 2.
stdout:
stderr:
stan/lib/stan_math/make/libraries:117: *** "Need to set TBB_CXX_TYPE for non-standard compiler other than gcc or clang.". Stop.
Hi, I ran into this error. Is there a solve? Not sure what issue is from your comment. Thanks for any help.
Brian Ward provided end user work around. see https://discourse.mc-stan.org/t/nutpie-and-stan-functionality/37077/6
What's happening is the following:
nutpie calls into bridgestan to convert the stan model code to c++ and compile this using code from the stan repository. The c++ code depends on TBB, a library from intel for multithreading. The TBB library it bundled together with stan. TBB seems to have some code that it wants to compile differently depending on if the c++ compiler is clang or gcc, and it seems to have some (not very reliable) code for figuring out which compiler it is dealing with. This code fails for the compiler in conda-forge. As a fallback TBB allows users to specify manually which compiler is being used, by setting the TBB_CXX_TYPE environment variable.
I'm not really sure where this should be fixed, but nutpie doesn't seem to be the right place I think?
@WardBrian I hope it is ok if I ping you here, do you think it would be possible to use a check like this one in the makefile of stan to set TBB_CXX_TYPE if necessary? I don't quite get why cmdstanpy isn't also running into this issue, maybe it has a different workaround?
Just to clarify, is everyone here running on Linux?
Setting TBB_CXX_TYPE could in principle be done as part of a custom Conda activation script, and I could help with this route. However doing so is far from ideal since there are lots of situations where the activation scripts fail to run, e.g. when people just set PATH. :man_facepalming:
If you install cmdstanpy from conda, you will also get cmdstan from conda, which sets this: https://github.com/conda-forge/cmdstan-feedstock/blob/main/recipe/build.sh#L12 (and some other flags, to actually just use TBB from conda on non-Windows)
We don't currently have a configure-like step, which I think would be the natural place to build a file like the one you linked to.
One potential option is to package bridgestan itself on conda-forge. This would probably be pretty easy if we extracted a lot of cmdstan's build into a stan-cxx package or something
Ah, that explains why this doesn't happen for cmdstan. A conda bridgestan package would indeed be nice :-)
For the snipped, I don't think you would have to compile anything though. I think you could run
$CXX -E -P check-compiler.cpp | grep -o "clang\|gcc\|msvc\|unknown"
in a makefile directly, it only has to run the preprocessor, not the full compiler.
Won't work for msvc directly though, because that doesn't accept -E, so it would need a special case, and in order to know which one to run we need the compiler family :-)
I don’t think Stan can even be compiled by MSVC as it stands today, so it would always be either gcc or clang I suspect