Describe the bug
Using cmdstanr::cmdstan_model compile model faces the error:
PCH file uses an older PCH format that is no longer supported
Operating system
Mac OS 10.15.7
CmdStanR version number
0.1.3
This program is workable on Linux Ubuntu when I use the same function.
https://github.com/stan-dev/cmdstanpy/issues/108
I notice a related issue in cmdstanpy. But I didn't get any hints there.
Hmm, can you try running rebuild_cmdstan() and then see if the error persists?
@jgabry
Interesting! It now works! Thank you!
This is an issue that pops up on macOS sometimes when xcode upgrades. I think it happens often enough that we should try to catch this error message and signal to the user that rebuild_cmdstan() is the solution.
Weirdly this does not pop up on Linux if I upgrade the clang compiler.
I am going to reopen this and we can close this once we have a way to suggest to the user to rebuild cmdstan.
I've hit this a couple of times and added a mention specifically of PCH files in the CmdStan doc. as the docs are not a very good solution, I like Rok's suggestion of trying to catch the error message and do the right thing.
@beyondpie glad it's working now. @rok-cesnovar @mitzimorris Yeah it would be great to catch this error.
One strange thing is:
rebuild_cmdstan(), then it works.But during this process, I didn't update my Xcode or Mac system...
So this happens every time? Or just once and now it will work?
Do you use any compile flags like stan_threads?
@rok-cesnovar
cmdstanr::cmdstan_model( my_stan_file, compile = T ) to compile the model. I notice there is a arg force_recompile = FALSE. I try to set it as T, but it's not useful.One more details:
error: PCH file uses a newer PCH format that cannot be readI don't know the details. But seems there is some cache during compiling ? And only when I rebuild_cmdstan(), the cache is cleared?
then I update the stan script, and try to compile again
by script you mean the model.stan file?
every time you update a Stan program and recompile, you get this error?
perhaps problem with the Makefile?
@mitzimorris
model.stan file. Maybe it's on my side.
Thanks for all the info.
If you can help us investigate this a bit more: Can you cmdstan_model(..., quiet = FALSE) and tell me if its compiled with g++ or clang?
Googling this a bit it seems this is Xcode related.
@rok-cesnovar
Yesterday, everything seems OK. But today I delete one comment line in the STAN script, then it failed again ...
Is that possible that I should not delete the old compiled one ?

I rebuild_cmdstan(), then it's OK.

@rok-cesnovar
Seems that, after rebuild_cmdstan(), the first step in make is different. Maybe some file exists, and makefile jumps to the next command before I rebuild_cmdstan() ?
Can you post the output of cmdstan_make_local()
99% is that it will return nothing, but just to double check.
Can you post the output of
cmdstan_make_local()
It returns character(0)
@rok-cesnovar
I compile the model in a R console repeatedly, not in the terminal. Hope this is fine.
Yeah, that should definitely not be a problem.
I keep seeing suggestions to set GCC_PRECOMPILE_PREFIX_HEADER=NO in Xcode, though I honestly have zero ideas on how to do that. I, unfortunately, have no experience with macOS.
Maybe:
cmdstan_make_local(cpp_options = "GCC_PRECOMPILE_PREFIX_HEADER=NO", append = TRUE)
rebuild_cmdstan()
which writes this in the makefile. But I doubt that.
What does
p <- processx::run("clang++", args = "--version")
cat(p$stdout)
return?
p <- processx::run("clang++", args = "--version") cat(p$stdout)
It returns:
Apple clang version 12.0.0 (clang-1200.0.31.1)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
Maybe:
cmdstan_make_local(cpp_options = "GCC_PRECOMPILE_PREFIX_HEADER=NO", append = TRUE) rebuild_cmdstan()which writes this in the makefile. But I doubt that.
Thanks. I will give it a try tomorrow morning because I notice that I face this compile issue every morning. Then it works in the day....
It returns:
are you sure there is not one more line before the Target line? That should have the clang version.
I will give it a try tomorrow morning because I notice that I face this compile issue every morning.
Thanks! Do this at the end of today and then if this repeats tomorrow morning we can dig further. Sorry for the troubles.
are you sure there is not one more line before the Target line? That should have the clang version.
Sorry for this. I correct the information.
Thanks! Do this at the end of today and then if this repeats tomorrow morning we can dig further. Sorry for the troubles.
Sure. Thank you very much! At least, I know rebuild_cmdstan() works when I face this issue.
One thing that comes to mind. Is this actually clang 12? Is that what install with Xcode on macOS? I think clang 11 is the last release and 12 is "develop".
Hmm, interesting. It definitely says clang 12 on my mac too:
jgabry@Jonahs-MacBook-Pro ~ % clang --version
Apple clang version 12.0.0 (clang-1200.0.32.21)
Target: x86_64-apple-darwin19.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
@rok-cesnovar
I follow this yesterday, but today I can still get the error.
cmdstan_make_local(cpp_options = "GCC_PRECOMPILE_PREFIX_HEADER=NO", append = TRUE)
rebuild_cmdstan()

Thanks!
Looking at your output I am not sure why there is a -I/usr/local/opt/llvm/include. I don't see that in my clang compile output.
Thanks!
Looking at your output I am not sure why there is a
-I/usr/local/opt/llvm/include. I don't see that in my clang compile output.
Yes. I notice that in my bash env, I add
export LDFLAGS="-L/usr/local/opt/llvm/lib -Wl,-rpath,/usr/local/opt/llvm/lib -L/usr/local/opt/openblas/lib"
export CPPFLAGS="-I/usr/local/opt/llvm/include -I/usr/local/opt/openblas/include"
I use this for other projects. Will this influence the compelling results ?
Ah okay, it probably should not, but clang is a part of llvm so that got me thinking in this direction and I have never seen that before.
Most helpful comment
This is an issue that pops up on macOS sometimes when xcode upgrades. I think it happens often enough that we should try to catch this error message and signal to the user that rebuild_cmdstan() is the solution.
Weirdly this does not pop up on Linux if I upgrade the clang compiler.
I am going to reopen this and we can close this once we have a way to suggest to the user to rebuild cmdstan.