[erlang-questions] Erlang on 64-bit ARM?

[Mikael Pettersson]

Frank Hunleth writes:
 > I was wondering if anyone uses Erlang on a 64-bit ARM platform
 > (aarch64)? The Buildroot project's CI servers are throwing linker
 > errors such as the following:
 > 
 >  LD /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/bin/aarch64-buildroot-linux-gnu/child_setup
 >  AR /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/erts/emulator/pcre/obj/aarch64-buildroot-linux-gnu/opt/libepcre.a
 >  LD /home/buildroot/autobuild/run/instance-0/output/build/erlang-17.5/bin/aarch64-buildroot-linux-gnu/beam
 > ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
 > In function `AO_double_compare_and_swap':
 > ethr_atomics.c:(.text+0x20): undefined reference to
 > `__atomic_compare_exchange_16'
 > ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
 > In function `AO_double_load':
 > ethr_atomics.c:(.text+0x3c): undefined reference to `__atomic_load_16'
 > ../lib/internal/aarch64-buildroot-linux-gnu/libethread.a(ethr_atomics.o):
 > In function `ethr_dw_atomic_cmpxchg_acqb':
 > ethr_atomics.c:(.text+0x5e8): undefined reference to `__atomic_load_16'
 > 
 > See http://autobuild.buildroot.net/results/0cd/0cd22eb74fa29e5a85bf897762e16ab3daf33962/build-end.log
 > for all of the error messages.
 > 
 > I was able to reproduce the same errors on the 18.2.1 release as well.
 > Possibly confounding the situation is that Buildroot crosscompiles
 > Erlang. However, Erlang builds fine on all other platforms supported
 > by Buildroot, and my attempt at reading the atomic intrinsics code was
 > leading me down the path that aarch64 may not be supported. Could
 > somewhere verify whether this is the case?

OTP 18.2.1 builds fine using an aarch64-unknown-linux cross toolchain built
using binutils-2.25.1, gcc-5.3.0, linux-3.19 kernel headers, and glibc-2.22,
all unmodified upstream sources.

However, if I also build and install libatomic_ops in that cross toolchain
and add --with-libatomic_ops to OTP's ./configure, then I do get the same
error as you cite above.

Looks like some issue in OTP's interface to that library.  I've never looked
into libatomics_ops myself, since I prefer to implement atomics by hand or by
using gcc's builtins.

Workaround for now is to not use libatomic_ops.  You may also want to file a
bug in the bug tracker.