Does the just released 10.15.1 update make the situation any better?
This all sounds really horrible…and I wonder if other RCpp based projects suffer from the same problems?
(I have not yet dared to upgrade)
AFAICT, both Rcpp::sourceCpp and inline::cxxfunction will not work under Catalina (if exceptions are thrown) because the linker uses the system version of libc++.0.dylib rather than the one supplied by R or the one supplied by clang-7.
Big list of Working/Not Working Apps here at least. Don’t know about other languages however
@wds15, 10.15.1 makes no difference. Same error occurs when sampling.
Chain 3: Iteration: 1 / 2000 [ 0%] (Warmup)
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " c++ exception (unknown reason)”
error occurred during calling the sampler; sampling not done
Yeah, although it’s curious that there are no open issues for either package (inline or Rcpp) that mention Catalina. I haven’t read the text of every issue but at least judging from all the issue titles it doesn’t seem like there are any. Any idea why not? If this isn’t just an RStan issue I would think this would be at the top of the priorities list for those packages (and they must be aware of it), but maybe I’m misunderstanding something relevant here.
I think it is just that not many people have upgraded to Catalina and even fewer are writing functions that branch on the exception type, that is getting mishandled by the combination of compilers and libraries being used. But it isn’t a Stan issue so someone that has Catalina and knows enough about compilation to be of help should post on R-SIG-Mac.
I’m on Catalina and have not been experiencing this issue, the readr/sourceRCPP repex also shows the expected ‘this is an exception’ for me.
I wonder if it could be because I use the homebrew R package? I can’t think of anything else that’s different about my system.
1 Like
Do you mean you use g++ from homebrew?
No, I’m definitely using clang, version 11.0.0 (clang-1100.0.33.8).
/usr/local/Cellar/r/3.6.1_1/lib/R/bin/R CMD SHLIB -o 'sourceCpp_3.so' --preclean 'file60348a82cd.cpp'
clang++ -arch x86_64 -ftemplate-depth-256 -I"/usr/local/Cellar/r/3.6.1_1/lib/R/include" -DNDEBUG -I"/usr/local/lib/R/3.6/site-library/Rcpp/include" -I"/private/var/folders/00/l8wh5r152f13_5xvrgh2slxw0000gn/T/RtmpZgCpyO/sourceCpp-x86_64-apple-darwin18.6.0-1.0.2" -I/usr/local/opt/gettext/include -I/usr/local/opt/readline/include -I/usr/local/include -fPIC -O3 -mtune=native -march=native -Wno-unused-variable -Wno-unused-function -c file60348a82cd.cpp -o file60348a82cd.o
clang++ -arch x86_64 -ftemplate-depth-256 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/opt/gettext/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -L/usr/local/Cellar/r/3.6.1_1/lib/R/lib -L/usr/local/opt/gettext/lib -L/usr/local/opt/readline/lib -L/usr/local/lib -o sourceCpp_3.so file60348a82cd.o -L/usr/local/Cellar/r/3.6.1_1/lib/R/lib -lR -lintl -Wl,-framework -Wl,CoreFoundation
>
> throw_exception()
Error in throw_exception() : this is an exception
But you are saying you got clang++ from homebrew rather than from @coatless installer or from https://cran.r-project.org/bin/macosx/tools ?
I’m pretty sure clang++ came from XCode. I don’t remember installing either the coatless software or the cran macosx tools you linked to.
BookTwo:bin $ which clang++
/usr/bin/clang++
BookTwo:bin $ clang++ --version
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
My R installation definitely came from homebrew (using brew install r), which is what I was trying to say above.
OK. It is known to be possible to avoid the mishandled exceptions if you avoid all of R’s clang stuff, but that is not a general enough workaround for us (or Rcpp / inline). In principle, everyone could just use Xcode but you lose out on the ability to use OpenMP and all the R packages compiled on CRAN that have Stan programs are still broken.
From reading @nicokist’s output, he’s using the homebrew compiler…
So, moving totally away from R’s official binary works… Maybe this should be escalated over to Simon (macOS CRAN maintainer)
If I had a Mac, I would. But I am not much use when I have to borrow someone else’s machine (that has Catalina) to respond to posts with test cases.
I can say that
Rcpp::sourceCpp(code =
'
#include <Rcpp.h>
using namespace Rcpp;
// [[Rcpp::export]]
int throw_exception() {
std::stringstream errmsg; errmsg << "this is an exception";
throw std::domain_error(errmsg.str());
return 0;
}
'
)
throw_exception()
works correctly (i.e. says “this is an exception”) if
- One uses
clang++on Linux - One uses homebrew’s R on a Mac with Catalina
- One uses Xcode’s
clang++on a Mac with Catalina, provided no other C++ packages from CRAN have previously been loaded
And the problem has not much to do with Stan, except that we call Rcpp::sourceCpp and inline::cxxfunction and throw exceptions at runtime. But even packages like rstanarm wiith Stan programs that are compiled in advance on CRAN are affected.
Any updates?
Still broken
If you are using Catalina with the recommended clang++ installer, try the advice in
2 Likes
Worked a treat - thank you! :)
Thank you for that! I have installed them a while ago, so I just ran the code you provided. However, after running it, my stan file could check its gramma once before it didn’t work again. Is there anything I’m not doing correctly? Thanks!
You may have to reinstall it from source at the moment with
install.packages("rstan", type = "source")