On Tue Jun 30 07:54:10 2026 +0000, Martin Storsjö wrote:
Sounds reasonable yes, to not bother with it, as it is consistent and nice all across aarch64. This update broke building for ARM32 though. We're using the constants `HWCAP_NEON` etc - but `bits/hwcap.h` on glibc only defines `HWCAP_ARM_NEON`, while `asm/hwcap.h` which we now no longer include defined `HWCAP_NEON`. I had a look around, and FreeBSD's `elf.h` defines `#define HWCAP_NEON 0x00001000`, glibc's `bits/hwcap.h` defines `#define HWCAP_ARM_NEON 4096`, musl's `bits/hwcap.h` defines both `#define HWCAP_NEON (1 << 12)` and `#define HWCAP_ARM_NEON (1 << 12)`. So for these, I would suggest either: - Go with glibc's naming and provide an unconditional define of our own (`#define HWCAP_ARM_NEON 4096`) - at least within the quick check of glibc/musl/freebsd, there's only one defining it, and with that value, so we should be free of conflicts. - Go with the freebsd/kernel naming, and define it with an `#ifndef`. There are only three of these constants that we use, so it's not that much of a pain to do. Erm, sorry, I must have been confused in my comment above. Even with the naming `HWCAP_ARM_NEON`, glibc and musl both define it, but with differing spelling. So even with that choice we do need an `#ifndef` it we don't want it to warn.
So I think we do need a fallback, with `#ifndef`, in either case. There's no single name that is universally defined by this set of three different system headers - unless we readd `<asm/hwcap.h>`, which is needed on glibc to define `HWCAP_NEON`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11267#note_144529