Based on https://stackoverflow.com/questions/9397065/android-armv6-v7-and-vfp-neon I think that this affects ARMv6 and older versions of the ARM ISA. ARMv7 is also known as "armhf" (hard floating point), but not all ARMv7 devices support the SIMD architecture NEON.

To my understanding, we only attempt to use some NEON instructions on ARMv8 (Aarch64), never in any 32-bit builds. That code should include appropriate run-time checks, which were last revised in MDEV-23495.

Thank you for commenting and clarifying this more. Docs says that ARMv7 should have NEON. Armel is targeted for ARMv5/6 and it's kind of good will to be buildable on that architecture (own opinion warning). I've posted first draft of CMake detection code on Salsa merge request which seemed to work pretty ok but I have to test with newer code that does it detect that one has NEON available.

Yes, the purpose of Debian is to be a universal operating system, and someone could want to run MariaDB Server on a Raspberry Pi 1 (ARMv6) or something even older. I haven’t seen your patch yet, but I believe that this should be fixable in CMake without invoking a compiler.

marko could you take a look at pull request is that correct solution?

illuusio, if I understood correctly, the problem occurs when we are cross-compiling to a 32-bit ARM ISA on 64-bit ARM (ARMv8, Aarch64). Based on the documentation of CMAKE_SYSTEM_PROCESSOR, I would tend to believe that the build environment is set up incorrectly, and CMAKE_SYSTEM_PROCESSOR should not match aarch64. The CMAKE_HOST_SYSTEM_PROCESSOR could, but we should not care about that.

Would it help to specify a CMAKE_TOOLCHAIN_FILE?

This is actually not cross-compiling but true ARM hardware on Debian Salsa-CI. They have provided ARM64 which should be down graded with

setarch linux32

but I haven't got that far or I don't know if that is happening.
Discussion in Salsa is here where I've also asked why ARMel is not 32bit build. Here is current setup of machine . It ends with errors as build log should be that long.

I made an experiment on AMD64, compiling a simple C++ project for IA-32, like this:

cmake -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_BUILD_TYPE=RelWithDebInfo ..

cmake --build .

This does produce 32-bit executables, but CMAKE_SYSTEM_PROCESSOR would be x86-64. I then tried the advice given in https://stackoverflow.com/questions/5805874/the-proper-way-of-forcing-a-32-bit-compile-using-cmake and created a toolchain file with the following contents:

# the name of the target operating system

set(CMAKE_SYSTEM_NAME Linux)

set(CMAKE_SYSTEM_PROCESSOR i386)

set(CMAKE_C_COMPILER gcc)

set(CMAKE_C_FLAGS -m32)

set(CMAKE_CXX_COMPILER g++)

set(CMAKE_CXX_FLAGS -m32)

Initially, I did not specify any CMAKE_SYSTEM_PROCESSOR, which would cause that variable to be the empty string, as per the following in my CMakeLists.txt:

MESSAGE("system: " ${CMAKE_SYSTEM_PROCESSOR})

I specified the toolchain file by

cmake -DCMAKE_TOOLCHAIN_FILE=toolchain.txt

I believe that using a toolchain file would be the correct way of building for ARMv7 and older architectures on ARMv8. If I understood it correctly, currently we may be compiling some ARMv8 specific code for older ISA versions, and never execute it because the runtime CPU feature detection would always fail.

Debian salsa doesn't have HOST_ARCH=armhf / armel per https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/salsa-ci.yml which seems to account for the computation using and arm64 file.

This would conform to https://wiki.debian.org/CrossCompiling.

https://github.com/MariaDB/server/pull/2893 (MDEV-32935) is probably also needed to make cross compilation work (and save us from hacking Debian architecture notation into various parts of our build system).

As said armel/armhf are for older CPUs (as widely used in some context). I noted also that it's build on AMD64 image as Debian does not seems to maintain 32-bit build image. On Salsa-CI .build-script there is

test "${BUILD_ARCH}" = "i386" && export BUILD_COMMAND="/usr/bin/setarch i686 ${BUILD_COMMAND}"

which would be also

test "${BUILD_ARCH}" = "armel" && export BUILD_COMMAND="/usr/bin/setarch linux32 ${BUILD_COMMAND}"

which would work both but then you probably drop to i586.

What comes to crosscompile it work as expected. As this PR fixes (practically) problem I wondering should this PR just dropped or more turned to toolchain style which would be the correct solution..

And yes we should get https://github.com/MariaDB/server/pull/2893 (MDEV-32935) in to make things more easier to maintain.

I think that crosscompiling is anything where the host ISA is different from the target ISA. The correct way to do crosscompiling with CMake seems to be CMAKE_TOOLCHAIN_FILE. For AMD64 and IA-32, adding -m32 to the compiler flags appears to work in practice, but it is not the correct way. For ARMv8 and the older 32-bit ARM ISA versions I do not think it can work correctly, because like danblack pointed out, the HWCAP bits may be completely different between ISA versions.

When it comes to the IA-32 ISA, I do not know if the executables would work on the original Intel® Pentium® (i586). I am pretty sure that they don’t work on anything older than that; we make use of 64-bit atomic memory operations, which depend on the lock cmpxchg8b of the f00f bug infame.

As topic was update to next level. I've done little bit research and noted that Galera tests ARM CRC32 functions in CMake at top level. It's bit ugly on building side but works.

I've dig up little bit `arm_acle.h` which holds those `___crc32` definations. If I understood correctly it actually does not need NEON. GCC documentation says that SIMD or NEON is used if they are available.

Would it be most elegant just disable `arm_neon.h` if it's not available?

Per pull request review - https://github.com/MariaDB/server/pull/2896#discussion_r1448172923

Happy with currently implementation in accounting for the ARMv8 R where neon is optional, especially as the neon isn't used - just a gateway to use a vmull_p64 (a PMULL) feature.

ARMv5 and ARMv6 - out of scope, Debian isn't cross building right in Salsa test though actual build at least isn't trying to compile crc32_arm64.c on arm

.