Your message dated Wed, 13 Aug 2025 15:19:29 +0100 with message-id <aJye8V2_Kki0K6-C@descent> and subject line Re: Bug#1103352: dxvk: FTBFS on armhf and other non-x86 non-aarch64 architectures: #error "Unknown CPU Architecture" has caused the Debian Bug report #1103352, regarding dxvk: FTBFS on armhf and other non-x86 non-aarch64 architectures: #error "Unknown CPU Architecture" to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact [email protected] immediately.) -- 1103352: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1103352 Debian Bug Tracking System Contact [email protected] with problems
--- Begin Message ---Source: dxvk Version: 2.6.1-1 Severity: serious Tags: upstream ftbfs experimental Justification: built successfully in the past on armhf dxvk 2.6.1 with DXVK Native enabled doesn't build successfully on armhf: > c++ -Isrc/wsi/libwsi.a.p -Isrc/wsi -I../src/wsi -Iinclude -I../include > -I../include/vulkan/include -I../include/spirv/include -Iinclude/native > -I../include/native -I../include/native/windows -I../include/native/directx > -I../subprojects/libdisplay-info/include -I/usr/include/SDL2 > -fdiagnostics-color=always -D_GLIBCXX_ASSERTIONS=1 -Wall -Winvalid-pch > -Wextra -std=c++17 -Wimplicit-fallthrough -Wno-missing-field-initializers > -Wno-unused-parameter -Wno-misleading-indentation -Wno-cast-function-type > -Wno-unused-const-variable -Wno-missing-braces -DDXVK_WSI_SDL2 -g -O2 > -ffile-prefix-map=/build/reproducible-path/dxvk-2.6.1=. > -fstack-protector-strong -fstack-clash-protection -Wformat > -Werror=format-security -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 > -D_TIME_BITS=64 -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -D_GNU_SOURCE=1 > -D_REENTRANT -MD -MQ src/wsi/libwsi.a.p/wsi_platform.cpp.o -MF > src/wsi/libwsi.a.p/wsi_platform.cpp.o.d -o > src/wsi/libwsi.a.p/wsi_platform.cpp.o -c ../src/wsi/wsi_platform.cpp > In file included from ../src/wsi/../util/util_string.h:10, > from ../src/wsi/../util/util_env.h:3, > from ../src/wsi/wsi_platform.cpp:4: > ../src/wsi/../util/util_bit.h:12:2: error: #error "Unknown CPU Architecture" — https://buildd.debian.org/status/fetch.php?pkg=dxvk&arch=armhf&ver=2.6.1-1&stamp=1744304328&raw=0 A crude way to mitigate this issue would be to limit compilation of DXVK Native to amd64, i386 and arm64 only, after which this bug could be downgraded to wishlist until a porter steps in to help; please let me know if you would like a MR for this. But of course ideally DXVK Native would be portable (I don't think there's any fundamental reason why it can't be compilable on every architecture). There seem to be two places in the dxvk codebase that #error out if the CPU architecture is not recognised. 1. src/util/util_bit.h There is some conditional-compilation of this form (pseudocode): #if (architecture is x86_64 or i386) #define DXVK_ARCH_X86 #if (architecture is x86_64) #define DXVK_ARCH_X86_64 #endif #elif (architecture is aarch64) #define DXVK_ARCH_ARM64 #else #error #endif But all the conditional compilation further down the file seems to have a portable "#else" fallback available, so probably it would be OK to replace the "#error" with just not defining any of the helper macros on unrecognised architectures? 2. src/util/sync/sync_spinlock.h The implementation of dxvk::sync::spin calls _mm_pause() on x86, uses inline assembly to call "yield" on aarch64, and emits a #error "Pause/Yield not implemented for this architecture." otherwise. For this to be portable, it would need a fallback for other architectures. Looking at https://codesearch.debian.net/search?q=_mm_pause&literal=1 it seems that a reasonable implementation for other architectures would be to do nothing at all (and porters can contribute an implementation for their architecture if they want to). smcv
--- End Message ---
--- Begin Message ---Version: 2.6.2-1 On Wed, 16 Apr 2025 at 17:45:32 +0100, Simon McVittie wrote: > dxvk 2.6.1 with DXVK Native enabled doesn't build successfully on armhf Fixed in experimental. 2.6.2 still FTFBS on armel for unrelated reasons, but the release team have announced that forky is not going to be available on armel[1] so it is probably not worth putting any effort into addressing that. Thanks, smcv [1] https://www.debian.org/releases/trixie/release-notes/issues.en.html#armel-last-release
--- End Message ---
