ARM 32-bit issues (again)

[claudioandre-br]

We can/should consider the 32-bit world in the past and ignore it completely.

The logic used to configure packages (in this case ARM) is not properly adjusted.

The congure detects that it is 32-bit, but then the SIMD tests (probably inside jtr_arm_logic.m4) force it to use a 64-bit header.

Let's dig into it:

:: -----------------------------------------------------------
:: Build system information
:: --------------------------------
:: Linux
:: armv7l
:: Linux bos03-arm64-023 6.8.0-51-generic #52-Ubuntu SMP PREEMPT_DYNAMIC Thu Dec  5 13:32:09 UTC 2024 armv7l armv7l armv7l GNU/Linux
:: --------------------------------
:: processor  : 0
:: model name  : ARMv8 Processor rev 1 (v8l)
:: BogoMIPS  : 50.00
:: Features  : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt lpae evtstrm fphp asimdhp asimddp aes pmull sha1 sha2 crc32 ssbs
:: CPU implementer  : 0x41
:: CPU architecture: 8
:: CPU variant  : 0x3
:: CPU part  : 0xd0c
:: CPU revision  : 1
:: --------------------------------
:: DISTRIB_DESCRIPTION="Ubuntu 24.04.1 LTS"
:: PRETTY_NAME="Ubuntu 24.04.1 LTS"

So it's arm 7 running on modern/up-to-date hardware.

But:

:: checking if gcc supports -m64... skipped
:: checking for 32/64 bit... 32-bit
[...]
:: checking special compiler flags... ARM
:: configure: Testing build host's native CPU features
:: checking for NEON... yes
:: checking for ASIMD... yes
:: checking if gcc supports -fno-strict-aliasing... yes
:: checking for extra ASFLAGS... None needed
:: checking for arch.h alternative... arm64le.h
[...]
:: Target CPU ......................................... armv7l ASIMD, 32-bit LE
:: Target OS .......................................... linux-gnueabihf
:: Cross compiling .................................... no
:: Legacy arch header ................................. arm64le.h

See also #5631.

• If the CPU being used supports something, it doesn't mean that the whole environment is this or that.
• Other checks are simply ignored.