mirror of
https://github.com/FFmpeg/FFmpeg.git
synced 2026-08-09 09:32:43 +00:00
7f6b35d6c8
Before ced4a6ebc9, we used constants
in the form HWCAP_NEON. In that commit, they were renamed to
HWCAP_ARM_NEON, to match the pattern used for aarch64 and PPC.
On PPC our naming is entirely custom to us, upstream headers
(from e.g. glibc) use an entirely different naming.
On aarch64, we use names similar to the system headers, where they
are named e.g. HWCAP_CRC32, but we add an extra prefix, naming them
HWCAP_AARCH64_CRC32, to avoid any potential conflict and redefinition
issues. (In practice, this isn't needed - both glibc, musl and
BSDs provide the aarch64 HWCAP_ defines with the same names and
same literal expansion.)
However, on ARM, the landscape of the HWCAP defines is much less
consistent. On glibc, <bits/hwcap.h> (which gets included by
<sys/auxv.h>) provides most constants with an HWCAP_ARM_ prefix.
(The couple newest constants lack that prefix though.)
The kernel headers, in <asm/hwcap.h>) define them with just a
HWCAP_ prefix, i.e. HWCAP_ARM_NEON vs HWCAP_NEON.
For the actual expansion, <asm/hwcap.h> defines HWCAP_NEON as
(1 << 12), while glibc <bits/hwcap.h> defines HWCAP_ARM_NEON
as 4096. Musl's <bits/hwcap.h> defines both HWCAP_NEON and
HWCAP_ARM_NEON, as (1 << 12).
The BSDs define HWCAP_NEON in <elf.h>, defined as 0x00001000.
Thus, all system headers define the constant with differing
expansions. And they differ in which name they expose for the
constants. But we provide our definitions in any case.
Due to all this, wrap our definitions in #ifndefs, to avoid warnings
about redefining the constants on glibc.