Title: armeabi-v7a build fails with multiple incompatibilities on 32-bit Android devices
Environment:
Platform: Android (armeabi-v7a, 32-bit ARM TV device)
NDK: 28.2.13676358
CMake: 3.22.1
Host OS: Windows
Description:
Attempting to build Vulkan-Samples for armeabi-v7a results in a series of failures, suggesting the project does not support 32-bit Android targets. The errors occur in sequence:
Error 1: ARMv8-only NEON intrinsic used on ARMv7
third_party/astc/Source/astcenc_vecmathlib_neon_4.h:1027 uses vqtbl1q_u8, which is an ARMv8 (AArch64) intrinsic not available on ARMv7. The third_party/CMakeLists.txt ASTC architecture detection falls into the else() branch for non-Apple platforms and runs FindAVX2, FindSSE41, FindSSE2, FindNEON — all of which are inappropriate for an ARMv7 Android cross-compilation target.
error: use of undeclared identifier 'vqtbl1q_u8'; did you mean 'vtbl1_u8'?
Error 2: AVX2 feature detection runs on ARM target
As a side effect of the same detection block, FindAVX2 is included and attempts to compile x86-only headers (immintrin.h) against an ARM target:
error: "This header is only meant to be used on x86 and x64 architecture"
Error 3: Narrowing conversion on 32-bit
components/filesystem/src/std_filesystem.cpp:52 implicitly narrows uintmax_t (unsigned long long, 64-bit) to size_t (unsigned int, 32-bit), which is an error under -Werror:
error: non-constant-expression cannot be narrowed from type 'uintmax_t'
(aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list
Error 4: Vulkan handle type incompatibility on 32-bit
The framework's template type mapping vk::CppType cannot resolve unsigned long long Vulkan handles on a 32-bit target, as VkRenderPass and similar handles are uint64_t on 32-bit platforms but the CppType specialization does not exist for that case:
error: no type named 'Type' in 'vk::CppType'
using Type = typename vk::CppType::Type;
This occurs in framework/vulkan_type_mapping.h:40, triggered through framework/core/vulkan_resource.h and framework/core/render_pass.h.
Summary:
The project appears to be designed exclusively for 64-bit targets. There is no armeabi-v7a guard in the build system, and multiple layers of the codebase are incompatible with 32-bit ARM:
third_party/CMakeLists.txt — ASTC arch detection runs x86 feature checks unconditionally on all non-Apple platforms, including ARM Android cross-compilation targets
third_party/astc — NEON backend uses ARMv8-only intrinsics with no ARMv7 fallback
components/filesystem — implicit 64-to-32-bit narrowing not guarded
framework — Vulkan handle type mapping breaks on 32-bit where handles are uint64_t non-pointer types
Request:
Could you either:
Officially document that armeabi-v7a is not a supported target, so users with 32-bit Android devices (e.g. older TV boxes) are aware, or
Add armeabi-v7a guards in the build system (at minimum in third_party/CMakeLists.txt) to produce a clear error message instead of cascading cryptic compile failures
Title: armeabi-v7a build fails with multiple incompatibilities on 32-bit Android devices
Environment:
Platform: Android (armeabi-v7a, 32-bit ARM TV device)
NDK: 28.2.13676358
CMake: 3.22.1
Host OS: Windows
Description:
Attempting to build Vulkan-Samples for armeabi-v7a results in a series of failures, suggesting the project does not support 32-bit Android targets. The errors occur in sequence:
Error 1: ARMv8-only NEON intrinsic used on ARMv7
third_party/astc/Source/astcenc_vecmathlib_neon_4.h:1027 uses vqtbl1q_u8, which is an ARMv8 (AArch64) intrinsic not available on ARMv7. The third_party/CMakeLists.txt ASTC architecture detection falls into the else() branch for non-Apple platforms and runs FindAVX2, FindSSE41, FindSSE2, FindNEON — all of which are inappropriate for an ARMv7 Android cross-compilation target.
error: use of undeclared identifier 'vqtbl1q_u8'; did you mean 'vtbl1_u8'?
Error 2: AVX2 feature detection runs on ARM target
As a side effect of the same detection block, FindAVX2 is included and attempts to compile x86-only headers (immintrin.h) against an ARM target:
error: "This header is only meant to be used on x86 and x64 architecture"
Error 3: Narrowing conversion on 32-bit
components/filesystem/src/std_filesystem.cpp:52 implicitly narrows uintmax_t (unsigned long long, 64-bit) to size_t (unsigned int, 32-bit), which is an error under -Werror:
error: non-constant-expression cannot be narrowed from type 'uintmax_t'
(aka 'unsigned long long') to 'size_t' (aka 'unsigned int') in initializer list
Error 4: Vulkan handle type incompatibility on 32-bit
The framework's template type mapping vk::CppType cannot resolve unsigned long long Vulkan handles on a 32-bit target, as VkRenderPass and similar handles are uint64_t on 32-bit platforms but the CppType specialization does not exist for that case:
error: no type named 'Type' in 'vk::CppType'
using Type = typename vk::CppType::Type;
This occurs in framework/vulkan_type_mapping.h:40, triggered through framework/core/vulkan_resource.h and framework/core/render_pass.h.
Summary:
The project appears to be designed exclusively for 64-bit targets. There is no armeabi-v7a guard in the build system, and multiple layers of the codebase are incompatible with 32-bit ARM:
third_party/CMakeLists.txt — ASTC arch detection runs x86 feature checks unconditionally on all non-Apple platforms, including ARM Android cross-compilation targets
third_party/astc — NEON backend uses ARMv8-only intrinsics with no ARMv7 fallback
components/filesystem — implicit 64-to-32-bit narrowing not guarded
framework — Vulkan handle type mapping breaks on 32-bit where handles are uint64_t non-pointer types
Request:
Could you either:
Officially document that armeabi-v7a is not a supported target, so users with 32-bit Android devices (e.g. older TV boxes) are aware, or
Add armeabi-v7a guards in the build system (at minimum in third_party/CMakeLists.txt) to produce a clear error message instead of cascading cryptic compile failures