Can you confirm whether the object compiled by Rcpp::sourceCpp() is using the system C++ standard library or the one provided by R? Try running this after compiling the C++ object:
/private/var/folders/b4/2422hswx71z8mgwtv4rhxchr0000gn/T/RtmpuZz5kZ/sourceCpp-x86_64-apple-darwin15.6.0-1.0.2/sourcecpp_47b76cd81e72/sourceCpp_2.so:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.6.0)
If you still see the issue even with everyone using R’s libc++, I will be surprised!
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Rcpp/libs/Rcpp.so:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/readr/libs/readr.so:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
/private/var/folders/lc/h55t9rqs08df0y000pnp61d40000gn/T/Rtmp0GWy17/sourceCpp-x86_64-apple-darwin15.6.0-1.0.2/sourcecpp_ced87afdaccc/sourceCpp_2.so:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 800.6.0)
which seems to confirm your haunch. So, do we need to make Rcpp::sourceCpp and inline::cxxfunction use R’s libc++.1.dylib somehow? Or is the only option to do the install_name_tool thing?
There should be a way to do this with some special flags in ~/.R/Makevars, but I’m not sure exactly how this could be accomplished yet. Overriding which standard library gets used by the compiler is a bit tricky, and requires some orchestration of flags both during compilation and linking.
install_name_tool is normally a simpler workaround, but I’m not sure if there’s a clear space for it to fit during Rcpp::sourceCpp().
Hi, sorry–as a new used I could not post more until 24hrs.
I think I figured out where to look (silly me, just needed verbose = TRUE).
I think it is here:
In file included from /usr/local/clang7/include/c++/v1/cstdlib:86:
/usr/local/clang7/include/c++/v1/stdlib.h:94:15: fatal error: ‘stdlib.h’ file not found #include_next <stdlib.h>
/Library/Frameworks/R.framework/Versions/3.6/Resources/library/Rcpp/libs/Rcpp.so:
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libc++.1.dylib (compatibility version 1.0.0, current version 1.0.0)
I am intermediate computer user and I am not sure what I am supposed to do to fix this issue.
@kevinushey Have you seen a Mac with Catalina where the install_name_tool makes exceptions work? On @ssp3nc3r’s Mac, I get the attached log where install_name_tool seems to work but exceptions continue to not work.
Maybe. But Rcpp::sourceCpp and inline::cxxfunction are loading the DLLs automatically, so I don’t see how those would ever work on a Catalina machine. Prior to Catalina, rstan was working with essentially
Hello, I am a new Stan user and just want to echo that I am having the exact same issue as other people here. It seems like conversation on this thread has fallen off in the past few days - was a permanent, consistent solution ever found? Thanks.
Docker is the only way I can work right now on the machines I “upgraded” to Catalina. It’s just amazing that Apple has bricked so many people. I have several friends who just can’t work until there is a simple solution.
For transparency: I posted about the issues with Catalina on official Stan Twitter so that users are warned. If you think I’ve mischaracterized the situation, let me know and I will update the info there (people with access to official Twitter can obviously do it themselves).
@torkar I just installed Docker ran a brms job with it but the error emerged for one of the chains:
m_demos_secular_age ← brm(auth_theta_st |weights(weight)~ s(age,by=religion_sample),family=gaussian(),
data=survey_data,
cores = 4,chains=4, iter = 5000,
file=“models/m_demos_secular_age”)
Compiling the C++ model
recompiling to avoid crashing R session
Start sampling
starting worker pid=1162 on localhost:11460 at 01:37:30.530
starting worker pid=1176 on localhost:11460 at 01:37:30.722
starting worker pid=1190 on localhost:11460 at 01:37:30.911
starting worker pid=1204 on localhost:11460 at 01:37:31.099
SAMPLING FOR MODEL ‘0c266c38e0747884b21cf03aad6cbcc2’ NOW (CHAIN 1).
Chain 1:
Chain 1: Gradient evaluation took 0.00253 seconds
Chain 1: 1000 transitions using 10 leapfrog steps per transition would take 25.3 seconds.
Chain 1: Adjust your expectations accordingly!
Chain 1:
Chain 1:
Chain 1: Iteration: 1 / 5000 [ 0%] (Warmup)
SAMPLING FOR MODEL ‘0c266c38e0747884b21cf03aad6cbcc2’ NOW (CHAIN 2).
Chain 2:
Chain 2: Gradient evaluation took 0.002729 seconds
Chain 2: 1000 transitions using 10 leapfrog steps per transition would take 27.29 seconds.
Chain 2: Adjust your expectations accordingly!
Chain 2:
Chain 2:
Chain 2: Iteration: 1 / 5000 [ 0%] (Warmup)
SAMPLING FOR MODEL ‘0c266c38e0747884b21cf03aad6cbcc2’ NOW (CHAIN 3).
Chain 3:
Chain 3: Gradient evaluation took 0.003116 seconds
Chain 3: 1000 transitions using 10 leapfrog steps per transition would take 31.16 seconds.
Chain 3: Adjust your expectations accordingly!
Chain 3:
Chain 3:
[1] “Error in sampler$call_sampler(args_list[[i]]) : "
[2] " c++ exception (unknown reason)”
error occurred during calling the sampler; sampling not done
SAMPLING FOR MODEL ‘0c266c38e0747884b21cf03aad6cbcc2’ NOW (CHAIN 4).
Chain 4:
Chain 4: Gradient evaluation took 0.002956 seconds
Chain 4: 1000 transitions using 10 leapfrog steps per transition would take 29.56 seconds.
Chain 4: Adjust your expectations accordingly!
Chain 4:
Chain 4:
Chain 4: Iteration: 1 / 5000 [ 0%] (Warmup)
Am I possibly doing/done something wrong? Have you had success sampling with each implementation of rstan? Does this extend to brms or any other package such as blavaan that acts as a wrapper for RStan?
You are running this on localhost:8787?!? I, and others, have used the Docker image now for a number of days and I haven’t seen that error on Docker :( Can you send a MWE (incl. data) that I can try to run to see what happens?
I was hoping it could be that I was doing something wrong since I’m unfamiliar with much computer science. What do you mean by running it on localhost:8787 exactly?