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

[Rickard Green]

On Sun, Jan 17, 2016 at 2:38 AM, Frank Hunleth
<fhunleth@REDACTED> wrote:
> 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?
>
> Thanks,
> Frank
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions

We unfortunately currently do not have an aarch64 machine here at OTP,
so we have not tried to build on this arch.

If you have a reasonably new gcc (at least 4.7 depending on arch)
supporting the __atomic_* builtins these will be detected and used
automatically when building OTP 18. If this is the case, you don't
need libatomic_ops. If your gcc only supports __sync_* builtins, you
want to use libatomic_ops instead. This since the __sync_* builtins
issue unnecessary memory barriers.

What does "erlang:system_info(ethread_info)" return if you build
without libatomic_ops?

Regards,
Rickard
-- 
Rickard Green, Erlang/OTP, Ericsson AB