Source: mesa
Version: 25.0.1-1
Severity: serious
Tags: ftbfs
Justification: fails to build from source (but built successfully in the past)
X-Debbugs-Cc: [email protected]
User: [email protected]
Usertags: armhf
User: [email protected]
Usertags: i386
The recent Mesa update failed to build on the armhf and i386 buildds,
probably as a result of:
> * rules: enable gfxstream
The error:
> In file included from ../src/vulkan/wsi/wsi_common.h:29,
> from
> ../src/gfxstream/guest/vulkan_enc/gfxstream_vk_private.h:58,
> from
> ../src/gfxstream/guest/vulkan_enc/ResourceTracker.cpp:13:
> ../src/gfxstream/guest/vulkan_enc/ResourceTracker.cpp: In member function
> ‘VkResult gfxstream::vk::ResourceTracker::on_vkGetFenceStatus(void*,
> VkResult, VkDevice, VkFence)’:
> ../src/gfxstream/guest/vulkan_enc/ResourceTracker.cpp:4905:23: error: format
> ‘%p’ expects argument of type ‘void*’, but argument 4 has type ‘VkFence’ {aka
> ‘long long unsigned int’} [-Werror=format=]
> 4905 | mesa_loge("Failed to find VkFence:%p", fence);
> | ~~~~~
> | |
> | VkFence {aka long
> long unsigned int}
Unfortunately VkFence and other Vulkan things are defined as a pointer
on most 64-bit architectures, but as a uint64_t on 32-bit.
I think this (and perhaps other messages) will probably need something
more like:
mesa_loge("Failed to find VkFence:%" PRIx64, (uint64_t) fence);
if it's meant to be portable to 32-bit architectures.
Or perhaps another way this could probably be resolved, if gfxstream is
not an essential feature, would be to enable it on 64-bit architectures
only ("ifeq ($(DEB_HOST_ARCH_BITS),64)" in d/rules).
smcv
