A curious case of fmemopen@GLIBC_2.2.5 on aarch64

[Dimitri John Ledkov]

fmemopen@GLIBC_2.2.5 symbol exists on x86_64 everywhere.
fmemopen@GLIBC_2.2.5 symbol exists on aarch64 in rhel/centos builds
fmemopen@GLIBC_2.2.5 symbol does not exist on aarch64 builds from pure
upstream / debian / ubuntu
fmemopen@GLIBC_2.2.5 is not listed in aarch64 abilists neither
upstream, nor in rhel/centos.

Upon fmemopen being fixed to be POSIX compliant and upgraded to 2.22
symbol version, the backwards compat symbol was added.

Binaires compiled on rhel7 aarch64 appear to not be portable to
non-rhel aarch64 OSes - see example at
https://github.com/elastic/go-quark/issues/33

Looking at patched glibc tree of centos 8 builds, it is not clear how
or why fmemopen@GLIBC_2.2.5 gets built, generated and exported on
aarch64.

How does rhel/centos glibc builds on arm64 achieve exporting
fmemopen@GLIBC_2.2.5 ?
Is there a way to export it as well from vanilla glibc builds on arm64?

I am pondering if it is a sensible local modification to patch aarch64
abilist to lower/add fmemopen 2.2.5 and move on with life.
But also this might be an ABI omission, but equally so old that maybe
it doesn't matter anymore.

-- 
Regards,

Dimitri.