Creating a native Aarch64 build of R on my M1 machine was surprisingly
straightforward. Here is a step-by-step instruction of what I did in case
someone wants to replicate it:
1. Install native homebrew as described in this blog post under “Multiple
Homebrews” (https://soffes.blog/homebrew-on-apple-silicon). You will need to
manually chown a bunch of directories, keep an eye on brew output
2. Install the following brew packages
brew install jpeg libpng libtiff pcre2 pkg-config tcl-tk xz zlib
Again, pay attention to brew output, it is possible that you will have to
manually reset ownership on some directories
3. Make sure that zlib can be discovered by pkg-config by making it’s pc file
discoverable
ln -s /opt/homebrew/Cellar/zlib/1.2.11/lib/pkgconfig/zlib.pc
/opt/homebrew/lib/pkgconfig/
4. Install patched gfortran, I used the precompiled package from here:
https://github.com/fxcoudert/gfortran-for-macOS/releases/tag/11-arm-alpha1
5. In config.site, add the paths to homebrew libraries:
CPPFLAGS=-I/opt/homebrew/include
LDFLAGS=-L/opt/homebrew/lib
Note: the R-admin manual tells to set CC, CXX, FC in config.sites, but it’s not
strictly necessary, the build will work without them
5. Run the configure script, I used
./configure --enable-R-shlib --without-x --enable-memory-profiling
--with-blas="-framework Accelerate”
Check that the summary makes sense. If PNG is disabled, it’s probably because
you forgot step 3
6. Build R
make -j4
7. Check that everything runs
bin/R
You should see something like "Platform: arm-apple-darwin20.2.0 (64-bit)” in
the startup message.
All core tests seems to pass and the performance is excellent.
I have tried building tidyverse and it blocked on testthat. It seems that
testthat uses a fairly old version of Catch which doesn’t detect platform
correctly and tries to use some x86 inline assembly during the arm build…
> On 23 Nov 2020, at 11:14, Prof Brian Ripley wrote:
>
> As a follow-up, I now have a preliminary native build of R (using a gfortran
> compiled from sources forked from GCC and using minor modifications of Tomas
> Kalibera's instructions).
>
> The check timing was 148s, with Aqua (not X11) Tcl/Tk built from the sources
> and no X11 support, so not quite 100% comparable.
>
> Building the compiler took 45m elapsed with 100% CPU most of the time: the
> machine (which has no fan) remained cool (unlike my MBP which has a fan but
> rarely runs it and does get warm to the touch).
>
> There is a preliminary write-up on 'arm64' Macs in R-devel's R-admin manual
> (the version on CRAN is as usual a few days behind).
>
> On 17/11/2020 14:57, Prof Brian Ripley wrote:
>> Mine (a 8GB MBA) arrived today, so I have started doing some comparisons.
>> For the CRAN build of R 4.0.3, §2.8 of R-admin recommends checking the
>> installation with
>> pdf("tests.pdf") ## optional, but prevents flashing graphics windows
>> Sys.setenv(LC_COLLATE = "C", LC_TIME = "C", LANGUAGE = "en")
>> tools::testInstalledBasic("both")
>> tools::testInstalledPackages(scope = "base")
>> tools::testInstalledPackages(scope = "recommended")
>> That took 454s (using Rosetta) against 895s for my late-2016 MBP (2.9GHz
>> i5): happily nothing untoward was reported (some recommended packages give
>> differences from reference output on both systems).
>> You need to install XQuartz to provide the X11() devices and support for
>> package Tcl/Tk: everything I tried using that worked as expected.
>> Having done that post-installation check I would happily use the Intel R on
>> an M1 machine.
>> We plan to check many of the Intel-compiled packages under Rosetta.
>> There are many hours of work ahead to build/test a native toolchain: our
>> goal is to have a native distribution for R 4.1.0 ca April 2021.
>
>
> --
> Brian D. Ripley, rip...@stats.ox.ac.uk
> Emeritus Professor of Applied Statistics, University of Oxford
>
> ___
> R-SIG-Mac mailing list
> R-SIG-Mac@r-project.org
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
___
R-SIG-Mac mailing list
R-SIG-Mac@r-project.org
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
