OpenXR-SDK: error compiling for Raspberry Pi armhf: "No architecture string known!"

[jimis]

This is about failing to cross-compile the OpenXR-SDK project, please redirect me if I'm at the wrong place.

The error is

openxr/src/common/platform_utils.hpp:75:2: error: "No architecture string known!"

From the code:

https://github.com/KhronosGroup/OpenXR-SDK/blob/288d3a7ebc1ad959f62d51da75baa3d27438c499/src/common/platform_utils.hpp#L48-L75

#elif (defined(__ARM_ARCH) && __ARM_ARCH >= 7 && (defined(__ARM_PCS_VFP) || defined(__ANDROID__))) || defined(_M_ARM)
#define XR_ARCH_ABI "armv7a-vfp"
#elif defined(__ARM_ARCH_5TE__)
#define XR_ARCH_ABI "armv5te"
// ...
#else
#error "No architecture string known!"

For my target __ARM_ARCH is set to 6 and the following ARM-related macros are defined:

#define __ARMEL__ 1
#define __ARM_32BIT_STATE 1
#define __ARM_ACLE 200
#define __ARM_ARCH 6
#define __ARM_ARCH_6KZ__ 1
#define __ARM_ARCH_ISA_ARM 1
#define __ARM_ARCH_ISA_THUMB 1
#define __ARM_EABI__ 1
#define __ARM_FEATURE_CLZ 1
#define __ARM_FEATURE_DSP 1
#define __ARM_FEATURE_LDREX 0x4
#define __ARM_FEATURE_QBIT 1
#define __ARM_FEATURE_SAT 1
#define __ARM_FEATURE_SIMD32 1
#define __ARM_FP 0xc
#define __ARM_FP16_ARGS 1
#define __ARM_FP16_FORMAT_IEEE 1
#define __ARM_PCS 1
#define __ARM_PCS_VFP 1
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __ARM_SIZEOF_WCHAR_T 4
#define __ARM_VFPV2__ 1

[rpavlik]

Hmm. Rats. OK, so I messed up. I have armhf as armv7a-vfp. (Which makes sense, I explicitly called out hardware floating point in the name just like the debian name.) I'm not sure why I didn't realize armhf is only armv6 instead of armv7. I wonder if this is a debian vs raspbian difference, that sounds familiar... https://registry.khronos.org/OpenXR/specs/1.0/loader.html#architecture-identifiers

On the plus side, the Android mapping is clear, and I don't think there are too many users of OpenXR on Linux on ARM, so we can probably fix the mistake if it makes sense. I am just not sure what would make sense here.

What version of rpi are you using? Is it unreasonable to insist on a 64-bit distro to get useful XR? (in case of mapping raspberry pi armhf to armv5te aka soft float) The other option, is to have the requirements artificially raised, make that package insist on armv7a instead of just armv6. Means it wouldn't work on rpi1 or 2 but I'm not sure it ever would have in a useful way there...

[rpavlik]

Yep. it's a raspbian (RasPiOS) quirk, to support RPi 1. Apparently RPi2 has a v7 even, it's just the 1 (and probably zero) with the armv6. Debian armhf does match my description added to the loader doc (armv7a with VFP).

"The port is necessary because the official Debian wheezy armhf release is compatible only with versions of the ARM architecture later than the one used on the Raspberry Pi (ARMv7-A CPUs and higher, vs the Raspberry Pi's ARMv6 CPU)."

So I think the right thing to do, is that when you're building for Raspbian, you configure for armhf + armv7a + vfp, and mark the result as not working on an rpi 1. Sorry for the focus on packages, I'm thinking of this from my perspective as the Debian package maintainer.

Speaking of which, is there a reason you're not just using the packaged version?

[jimis]

I'm cross compiling for Raspberry Pi OS 32-bit based on Debian 11, the one reported as "legacy" at:
https://www.raspberrypi.com/software/operating-systems/
The target device is anything from Raspberry Pi 1 or Zero, even Raspberry Pi 4 with 64-bit OS should be able to run the 32-bit binaries.

No it's not unreasonable to require 64-bit distro. I don't plan to do any VR on the original Pi, it's just that OpenXR SDK is compiled by default when building latest Qt from the git repository. I can turn it off, but I thought I should report the issue.

[rpavlik]

Oh hmm. I wonder why Qt wants OpenXR and what it's doing with it. (and if it would break if we built openxr for ARMv7 instead of ARMv6, if it would fail gracefully)

In any case, it's also probably safe to just turn off that openxr dependency on arm 32-bit for raspberry pi os

[jimis]

is there a reason you're not just using the packaged version?

Qt bundles a version of OpenXR and as such, Qt compilation fails when compiling that part.
I didn't know OpenXR was packaged in RPiOS. Will try again.

Thank you for the quick response!

[rpavlik]

I mean OpenXR is packaged in Debian, they could have removed it from RPiOS.

Looks like an RPiOS "armhf" package should depend additionally on armv7-support and build with armv7 as the architecture, which would make it equivalent to the Debian meaning of "armhf". (Debian only has armv7-support as an armel package, but RPiOS changes the meaning of "armhf" to ARMv6 rather than ARMv7 so hopefully RPiOS has an armhf copy of it...)

And yeah in general I think for 32 bit RPiOS just turn off QT_FEATURE_quick3dxr_openxr. Might want to raise a Qt issue there, not sure if it's their problem or a packaging problem.

[rpavlik]

Can you try to see if applying this change fixes the build? #464

[jimis]

Compiles successfully with the patch applied, thank you!