R on ARM Mac M1:load failed for ‘stats’ and Rlog1p error about r-base-feedstock

[akrherz]

FWIW, I found with conda-forge/r-sf-feedstock#66 that adding the following in recipe/build.sh was sufficient to get a successful build.

export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P"

I did not attempt testing if the compiled package worked or not.

[skullcap4704]

FWIW, I found with conda-forge/r-sf-feedstock#66 that adding the following in recipe/build.sh was sufficient to get a successful build.

export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P"

I did not attempt testing if the compiled package worked or not.

Thanks! this works for me on installing the R package sctransform in M1 Pro Max:

This is the error I met:

error: no member named 'Rlog1p' in namespace 'std'; did you mean simply 'Rlog1p'?

I first run export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P" in the terminal and then install the package in R.

It doesn't work properly. So I modified CPPFLAGS on $R_HOME/etc/Makeconf, It worked!

[Br1anChou]

This is due to the ARM processor, you need to download the arm64 packages from CRAN or Bioconductor and compile it manually, like R CMD INSTALL XXX.tgz

[genecell]

FWIW, I found with conda-forge/r-sf-feedstock#66 that adding the following in recipe/build.sh was sufficient to get a successful build.

export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P"

I did not attempt testing if the compiled package worked or not.

Thanks! this works for me on installing the R package sctransform in M1 Pro Max:

This is the error I met:

error: no member named 'Rlog1p' in namespace 'std'; did you mean simply 'Rlog1p'?

I first run export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P" in the terminal and then install the package in R.

[mfansler]

@skullcap4704 interesting. That might be a better solution for Conda Forge, i.e., we might want to consider adding the flag generally by having r-base deliver a modified lib/R/etc/Makeconf with the flag.

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)

[znmeb]

I can reproduce the Rlog1p erroron an NVIDIA Jetson (arm64) using the current mambaforge installer in Docker. I've got time to troubleshoot if it will help.

> install.packages("RcppArmadillo")
trying URL 'https://ftp.osuosl.org/pub/cran/src/contrib/RcppArmadillo_0.10.7.3.0.tar.gz'
Content type 'application/x-gzip' length 1360186 bytes (1.3 MB)
==================================================
downloaded 1.3 MB

* installing *source* package 'RcppArmadillo' ...
** package 'RcppArmadillo' successfully unpacked and MD5 sums checked
** using staged installation
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether aarch64-conda-linux-gnu-c++ -std=gnu++14 accepts -g... yes
checking how to run the C++ preprocessor... aarch64-conda-linux-gnu-c++ -std=gnu++14 -E
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether aarch64-conda-linux-gnu-c++ -std=gnu++14 accepts -g... (cached) yes
checking whether we have a suitable tempdir... /tmp
checking whether R CMD SHLIB can already compile programs using OpenMP... yes
checking LAPACK_LIBS... system LAPACK found
configure: creating ./config.status
config.status: creating inst/include/RcppArmadilloConfigGenerated.h
config.status: creating src/Makevars
** libs
aarch64-conda-linux-gnu-c++ -std=gnu++11 -I"/home/synth/miniconda3/envs/r-reticulate/lib/R/include" -DNDEBUG  -I'/home/synth/miniconda3/envs/r-reticulate/lib/R/library/Rcpp/include' -DNDEBUG -D_FORTIFY_SOURCE=2 -O2 -isystem /home/synth/miniconda3/envs/r-reticulate/include -I/home/synth/miniconda3/envs/r-reticulate/include -Wl,-rpath-link,/home/synth/miniconda3/envs/r-reticulate/lib  -I../inst/include  -fpic  -fvisibility-inlines-hidden  -fmessage-length=0 -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O3 -pipe -isystem /home/synth/miniconda3/envs/r-reticulate/include -fdebug-prefix-map=/home/conda/feedstock_root/build_artifacts/r-base-split_1638516584669/work=/usr/local/src/conda/r-base-4.1.1 -fdebug-prefix-map=/home/synth/miniconda3/envs/r-reticulate=/usr/local/src/conda-prefix  -c RcppArmadillo.cpp -o RcppArmadillo.o
In file included from /home/synth/miniconda3/envs/r-reticulate/lib/R/library/Rcpp/include/RcppCommon.h:74,
                 from ../inst/include/RcppArmadilloForward.h:25,
                 from ../inst/include/RcppArmadillo.h:29,
                 from RcppArmadillo.cpp:21:
../inst/include/armadillo_bits/eop_aux.hpp: In static member function 'static typename arma::arma_integral_only<T>::result arma::eop_aux::Rlog1p(eT)':
/home/synth/miniconda3/envs/r-reticulate/lib/R/include/Rmath.h:75:15: error: 'Rlog1p' is not a member of 'std'; did you mean 'log1p'?
   75 | #define log1p Rlog1p
      |               ^~~~~~
../inst/include/armadillo_bits/eop_aux.hpp:99:124: note: in expansion of macro 'log1p'
   99 |   template<typename eT> arma_inline static typename   arma_integral_only<eT>::result log1p (const eT  x) { return eT( std::log1p(double(x)) ); }
      |                                                                                                                            ^~~~~
../inst/include/armadillo_bits/eop_aux.hpp: In static member function 'static typename arma::arma_real_only<T>::result arma::eop_aux::Rlog1p(eT)':
/home/synth/miniconda3/envs/r-reticulate/lib/R/include/Rmath.h:75:15: error: 'Rlog1p' is not a member of 'std'; did you mean 'log1p'?
   75 | #define log1p Rlog1p
      |               ^~~~~~
../inst/include/armadillo_bits/eop_aux.hpp:100:120: note: in expansion of macro 'log1p'
  100 |   template<typename eT> arma_inline static typename       arma_real_only<eT>::result log1p (const eT  x) { return std::log1p(x);
      }
      |                                                                                                                        ^~~~~
../inst/include/armadillo_bits/fn_misc.hpp: In function 'typename arma::arma_real_only<T>::result arma::log_add_exp(eT, eT)':
/home/synth/miniconda3/envs/r-reticulate/lib/R/include/Rmath.h:75:15: error: 'Rlog1p' is not a member of 'std'; did you mean 'log1p'?
   75 | #define log1p Rlog1p
      |               ^~~~~~
../inst/include/armadillo_bits/fn_misc.hpp:172:26: note: in expansion of macro 'log1p'
  172 |     return (log_a + std::log1p(std::exp(negdelta)));
      |                          ^~~~~
make: *** [/home/synth/miniconda3/envs/r-reticulate/lib/R/etc/Makeconf:177: RcppArmadillo.o] Error 1
ERROR: compilation failed for package 'RcppArmadillo'
* removing '/home/synth/miniconda3/envs/r-reticulate/lib/R/library/RcppArmadillo'

The downloaded source packages are in
        '/tmp/RtmpJaPZdK/downloaded_packages'
Updating HTML index of packages in '.Library'
Making 'packages.html' ... done
Warning message:
In install.packages("RcppArmadillo") :
  installation of package 'RcppArmadillo' had non-zero exit status
>

[yfyang86]

This issue is too old and is solved according to the above discussions. I will close it.

[isuruf]

@conda-forge/help-osx-arm64, looks like checking for rlog1p is disabled in cross compiling mode.

[yfyang86]

@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.

[znmeb]

@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 arm64 image.

[znmeb]

@yfyang86 Done. Repository is https://github.com/AlgoCompSynth/RcppArmadillo-crash-dockerfile. In the process of building it I "accidentally" discovered that RcppArmadillo installs successfully with R 3.6.3 but not with R 4.1.1. One thing you might want to check is the build processes for the Rmath library. https://cran.r-project.org/doc/manuals/r-release/R-admin.html#The-standalone-Rmath-library. In the failure that led me to this issue, Rmath was prominent in the error messages.

I'll try my issue (package warbleR) tomorrow, although dropping back to R 3.6.3 isn't an option.

[znmeb]

FWIW, I found with conda-forge/r-sf-feedstock#66 that adding the following in recipe/build.sh was sufficient to get a successful build.

export PKG_CPPFLAGS="-DHAVE_WORKING_LOG1P"

I did not attempt testing if the compiled package worked or not.

I'll try that with warbleR - that's the package I was having trouble with.

[znmeb]

Yep - warbleR compiles with this definition in place.

[isuruf]

We need to set some variables. Here's a list thanks to @erykoff,

r_cv_size_max, ac_cv_c_stack_direction, r_cv_putenv_unset, r_cv_putenv_unset2, r_cv_func_calloc_works, r_cv_func_isfinite_works, r_cv_func_log1p_works, r_cv_working_ftell, r_cv_func_sigaction_works, r_cv_mktime_errno, r_cv_working_mktime, r_cv_func_ctanh_works, r_cv_icu, r_cv_header_zlib_h, r_cv_have_bzlib, r_cv_have_lzma, r_cv_have_pcre2utf, r_cv_have_pcre832, r_cv_have_curl728, r_cv_have_curl_https, r_cv_kern_usrstack, r_cv_libc_stack_end, ac_cv_func_mmap_fixed_mapped, r_cv_openmp_simdred

[mfansler]

In case anyone else finds exporting isn't sufficient, here's another example situation. For r-ade, the package's src/Makevars already defined PKG_CPPFLAGS, so the export directive gets ignored. Instead we insert the flag via sed:

sed -ie 's/PKG_CPPFLAGS =/PKG_CPPFLAGS = -DHAVE_WORKING_LOG1P/' src/Makevars

For anyone doing an interactive install in R (as above), the withr package has functions for similar on the fly modifications to the Makevars.

[wolfv]

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 Rmath.h file. This file looks like the following on the natively compiled:

#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:

checking for working isfinite... yes
checking for working log1p... yes
checking whether ftell works correctly on files opened for append... yes
checking for working sigaction... yes

So I am not sure why the Rconfig.h file does not include HAVE_WORKING_LOG1P.

The check in autotools does something like this:

## R_FUNC_LOG1P
## ------------
## Suggested by Nelson H. F. Beebe <[email protected]> to deal with
## inaccuracies on at least NetBSD 1.6 and OpenBSD 3.2.
## However, don't test all the way into denormalized x (he had k > -1074)
## and at x = 2^-54 (d - x)/x is around 3e-17.
AC_DEFUN([R_FUNC_LOG1P],
[AC_CACHE_CHECK([for working log1p], [r_cv_func_log1p_works],
[AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <math.h>
#include <stdlib.h>
#include "confdefs.h"
int main (void) {
#ifdef HAVE_LOG1P
  int k;
  double d;
  double x = 1.0;
  for(k = 0; k < 53; k++) x /= 2.0;

  /* log(1+x) = x - (1/2)x^2 + (1/3)x^3 - (1/4)x^4 ... */
  /*          = x for x sufficiently small */
  for(k = -54; k > -1022; --k) {
    x /= 2.0;
    if(x == 0.0)
      exit(0);			/* OK: reached underflow limit */
    d = log1p(x);
    if(d == 0.0)
      exit(1);			/* ERROR: inaccurate log1p() */
    /* for large k, ((1/2)x^2)/x might appear in the guard digits */
    if(k < -80 && d != x)
      exit(1);			/* ERROR: inaccurate log1p() */
  }
  exit(0);
#else
  exit(1);
#endif
}
]])],
               [r_cv_func_log1p_works=yes],
               [r_cv_func_log1p_works=no],
               [r_cv_func_log1p_works=no])])
if test "x${r_cv_func_log1p_works}" = xyes; then
  AC_DEFINE(HAVE_WORKING_LOG1P, 1,
            [Define if log1p() exists and is accurate enough.])
  RMATH_HAVE_WORKING_LOG1P="# define HAVE_WORKING_LOG1P 1"
else
  RMATH_HAVE_WORKING_LOG1P="# undef HAVE_WORKING_LOG1P"
fi
AC_SUBST(RMATH_HAVE_WORKING_LOG1P)
])# R_FUNC_LOG1P

Interestingly the Windows Makefile also seems to replace the value (hardcoded):

Rmath.h0: Rmath.h0.in $(R_HOME)/VERSION Makefile.win
	@$(SED) \
	  -e  's/@RMATH_HAVE_WORKING_LOG1P@/# define HAVE_WORKING_LOG1P 1/' \
	  -e "s/@PACKAGE_VERSION@/`sed 's/\([^ ]*\).*/\1/' < $(R_HOME)/VERSION`/" $< > Rmath.h0

So I think it should be easy to follow this patch on Windows and just replace @RMATH_HAVE_WORKING_LOG1P@ with the correct value in Rmath.h0.in.

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 sed line tomorrow :)

[isuruf]

See #163 (comment)

[wolfv]

OK, I made the fixes as requested in #314. Curious if that's going to work :)

[mbargull]

Builds from gh-314 should fix this for macOS.
We would need the same for the Linux cross-compiled builds acc. to #163 (comment) .
The configure logs from gh-314 also show checking for working log1p... no for linux-aarch64/linux-ppc64le.
Might make sense to compare with the configure logs from native builds of those platforms to gauge what's applicable.

[isuruf]

Hmm, that's true. We had native builds until recently where this issue didn't come up.

[isuruf]

Fixed in #316 and #314