[R-SIG-Mac] Linker warnings and error when building R on Apple silicon

[Mikael Jagan]

Oops - forgot to mention: I am trying to build R-devel, currently at r81706.

Mikael

On 2022-02-10 12:13 pm, Mikael Jagan wrote:
> Hello,
> 
> I am running Big Sur on an M1 Mac and trying to build R from sources.
> Some system details:
> 
> R> sessionInfo()
>  > Platform: aarch64-apple-darwin20 (64-bit)
>  > Running under: macOS Big Sur 11.6.3
> 
> $ clang --version
>  > Apple clang version 13.0.0 (clang-1300.0.29.30)
>  > Target: arm64-apple-darwin20.6.0
> 
> $ /opt/R/arm64/gfortran/bin/gfortran --version
>  > GNU Fortran (GCC) 11.0.0 20201219 (experimental)
> 
> It has been a few months since I last built R on this machine.
> At the time, I was building with LLVM clang rather than Apple clang
> to obtain OpenMP support. I was recently nudged about the OpenMP
> runtime library made available here:
> 
> https://mac.r-project.org/openmp/
> 
> which would allow me to build "normally" with Apple clang.
> I am trying now to make the switch.
> 
> I have installed all of the binaries hosted here
> 
> https://mac.r-project.org/bin/darwin20/arm64/
> 
> rather than those hosted here
> 
> https://mac.r-project.org/libs-arm64/
> 
> which I had previously installed. (Though: the first URL is missing
> binaries for gfortran, pandoc, tcl, tk, and tkTable. I obtained
> these from the second URL. _Both_ URLs are missing a zlib binary,
> so I reluctantly obtained zlib from Homebrew.)
> 
> Anyway, I'm running into trouble now... I have attached my
> config.site, config.log, and build.out (from 'make >&') ...
> config.log seems completely normal, but in build.out I see
> many linker warnings of the form
> 
>  > ld: warning: could not create compact unwind for _dchdc_: registers 72 and 73 
> not saved contiguously in frame
>  > ld: warning: could not create compact unwind for _dpoco_: registers 72 and 73 
> not saved contiguously in frame
>  > ld: warning: object file (/opt/R/arm64/lib/libreadline.a(history.o)) was 
> built for newer macOS version (20.0) than being linked (11.0)
>  > ld: warning: object file 
> (/opt/R/arm64/lib/liblzma.a(liblzma_la-alone_decoder.o)) was built for newer 
> macOS version (20.0) than being linked (11.0)
> 
> And the build eventually fails for a seemingly unrelated
> reason:
> 
>  > clang -arch arm64 -dynamiclib -Wl,-headerpad_max_install_names -undefined 
> dynamic_lookup -single_module -multiply_defined suppress -falign-functions=64 -g 
> -O2 -Wall -pedantic -Wno-implicit-function-declaration -flto=thin -fPIC 
> -Wl,-mllvm,-threads=4 -L/opt/homebrew/opt/zlib/lib -L/opt/R/arm64/lib 
> -L/usr/local/lib -lomp -o tools.so text.o init.o Rmd5.o md5.o signals.o 
> install.o getfmts.o http.o gramLatex.o gramRd.o pdscan.o -Wl,-framework 
> -Wl,CoreFoundation
> mkdir ../../../../library/tools/libs
>  > installing 'sysdata.rda'
>  > Error in dyn.load(file, DLLpath = DLLpath, ...) :
>  >   unable to load shared object 
> '/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so':
>  >   dlopen(/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so, 
> 6): Symbol not found: _INTEGER
>  >   Referenced from: 
> /Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so
>  >   Expected in: flat namespace
>  >  in /Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so
>  > Error: unable to load R code in package 'tools'
>  > Execution halted
> 
> I've seen (and ignored) the "compact unwind" warnings before.
> I've come across suggestions to append '-Wl,-no_compact_unwind'
> to LDFLAGS, but it is not obvious to me that that is safe.
> 
> The warnings about macOS version mismatch are new, and strange,
> given that 20 is my Darwin version and 11 is my macOS version.
> I have tried all of
> 
> CC=clang
> CC="clang -target arm64-apple-macos11"   [copied from an example in R-admin]
> CC="clang -arch arm64"                   [copied from CRAN's Makeconf]
> 
> (and similarly for CXX) to no avail. I can trick the linker
> with '-target arm64-apple-macos20' but that doesn't seem safe
> either.
> 
> I'd be grateful for any hints on how to get things working,
> again.
> 
> Mikael