-
-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
R on ARM Mac M1:load failed for ‘stats’ and Rlog1p error #163
Comments
@conda-forge/help-osx-arm64, looks like checking for rlog1p is disabled in cross compiling mode. |
I can reproduce the
|
@znmeb This suggestion may help. It would be great if you could share the Dockerfile (and docker configuration) to reproduce the issue. I only tried triton alike on Jetson Kit, but no experience on R (on Jetson) yet. |
@yfyang86 OK ... let me strip all the extraneous stuff out - the image is 6 GB at the moment and I can probably make it happen on the default Ubuntu 18.04 |
@yfyang86 Done. Repository is https://github.com/AlgoCompSynth/RcppArmadillo-crash-dockerfile. In the process of building it I "accidentally" discovered that I'll try my issue (package |
FWIW, I found with conda-forge/r-sf-feedstock#66 that adding the following in export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P" I did not attempt testing if the compiled package worked or not. |
I'll try that with |
Yep - |
We need to set some variables. Here's a list thanks to @erykoff,
|
Thanks! this works for me on installing the R package This is the error I met:
I first run |
In case anyone else finds exporting isn't sufficient, here's another example situation. For sed -ie 's/PKG_CPPFLAGS =/PKG_CPPFLAGS = -DHAVE_WORKING_LOG1P/' src/Makevars For anyone doing an interactive install in R (as above), the |
This is due to the ARM processor, you need to download the arm64 packages from CRAN or Bioconductor and compile it manually, like |
This issue is too old and is solved according to the above discussions. I will close it. |
It doesn't work properly. So I modified CPPFLAGS on $R_HOME/etc/Makeconf, It worked! |
@skullcap4704 interesting. That might be a better solution for Conda Forge, i.e., we might want to consider adding the flag generally by having Right now we're multiplying our efforts by having to add the workaround to each R package feedstock. @conda-forge/r thoughts? (@yfyang86 I'm reopening as I think this still merits discussion) |
I have dug a little bit and compiled r-base with conda-build locally on a osx-arm64 machine. I think the main problem lies in the generated #ifndef HAVE_WORKING_LOG1P
# define HAVE_WORKING_LOG1P 1
#endif
#if !defined(HAVE_WORKING_LOG1P)
/* remap to avoid problems with getting the right entry point */
double Rlog1p(double);
#define log1p Rlog1p
#endif And on the cross-compiled, conda-forge version it looks like this: #ifndef HAVE_WORKING_LOG1P
# undef HAVE_WORKING_LOG1P
#endif
... I do see the following in the local autotools logs:
So I am not sure why the The check in autotools does something like this:
Interestingly the Windows Makefile also seems to replace the value (hardcoded):
So I think it should be easy to follow this patch on Windows and just replace I don't have a lot of autotools-fu so I am not sure if there would also be a good way to override that check. Maybe @isuruf, since we briefly discussed this today, you have some more ideas? Otherwise I can send a PR with the |
See #163 (comment) |
OK, I made the fixes as requested in #314. Curious if that's going to work :) |
Builds from gh-314 should fix this for macOS. |
Hmm, that's true. We had native builds until recently where this issue didn't come up. |
Issue:
Environment (
conda list
):Details about
conda
and system (conda info
):Issue 1 (see solution later):
When I start the R console, it shows
Issue 2 (Details RcppArmadillo330)
When using
Rcpp
, it will fail onstd::log1p
, i.e.HAVE_WORKING_LOG1P
is not detected in R configuration stage.Possible Solutions
ISSUE1/ISSUE2
a.
___kmpc_for_static_fini
is related to openMP, hence for the current environment,--disable-openmp
might work;b. There is no reason to use OpenBLAS since some benchmarks illustrate that vecLib outperforms OpenBLAS alike. Besides, I came across the same
FFLAG
errors when compiling R--with-BLAS-shlib
.I recompiled R with the following options (without X, and veclib should be replaced by
-framework Accelerate
):Both issues vanish.
The text was updated successfully, but these errors were encountered: