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

[Prof Brian Ripley]

On 10/02/2022 17:28, Mikael Jagan wrote:
> 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.)

zlib is part of the OS.  For pkg-config you need the zlib stub available 
from https://mac.r-project.org/libs-4/.  That *is* in the R-admin 
manual.  Also, that tcl, tk, and tkTable can be installed as part of an 
R binary installation.

For pandoc I use the official Intel builds under emulation without any 
problems (including checking all of CRAN).  But you don't need pandoc to 
build R.

I understand that the transition to https://mac.r-project.org/bin is 
work in progress, but its newer versions of libs are preferred.

>>
>> 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)

Hmm, that's about a binary liblzma.  I'd download again (maybe try both 
sites), and if it is still wrong, build from the sources.
>> 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.

They can be ignored: they are from the use of gfortran which does not 
fully use Apple conventions.

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

But that is not the issue, which is

 >> 
dlopen(/Users/mikael/Desktop/R/R-devel-build/library/tools/libs/tools.so,
 >> 6): Symbol not found: _INTEGER

Now tools.so should require that symbol, and it is linked to libR.dylib
which supplies it:

auk2% nm -g library/tools/libs/tools.so | grep _INTEGER
                  U _INTEGER

auk2% otool -L library/tools/libs/tools.so
library/tools/libs/tools.so:
	tools.so (compatibility version 0.0.0, current version 0.0.0)
	libR.dylib (compatibility version 4.2.0, current version 4.2.0)
	/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1856.105.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current 
version 1311.0.0)

auk2% nm -g lib/libR | grep _INTEGER
libR.dylib*       libRblas.dylib*   libRlapack.dylib*
auk2% nm -g lib/libR.dylib  | grep _INTEGER
0000000000103490 T _INTEGER

which comes from

auk2% nm -g src/main/memory.o | grep _INTEGER
00000000000066a8 T _INTEGER

So my next step would be to investigate the building of libR.dylib.

BTW, if one symbol is missing likely many are -- linkers usually only 
report the first one they encounter.

>>
>> I'd be grateful for any hints on how to get things working,
>> again.
>>
>> Mikael
> 


-- 
Brian D. Ripley,                  ripley using stats.ox.ac.uk
Emeritus Professor of Applied Statistics, University of Oxford