fix(cmake): detect Debian multiarch tuple for Qt6GuiPrivate path probe#3159
Conversation
The GPU spectrum fallback path check hardcoded x86_64-linux-gnu, so Qt6GuiPrivate was not found on aarch64 (Raspberry Pi 5) even with qt6-base-private-dev installed. Use dpkg-architecture -qDEB_HOST_MULTIARCH to detect the correct multiarch path at configure time, making the probe work on any Debian target (aarch64-linux-gnu, armhf-linux-gnueabihf, x86_64-linux-gnu, etc.). Falls back gracefully if dpkg-architecture is absent. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Per triage recommendation: explicitly initialize DEB_HOST_MULTIARCH to empty and use find_program(DPKG_ARCH dpkg-architecture) before calling execute_process, so the variable state is well-defined on systems where dpkg-architecture is not on PATH. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
There was a problem hiding this comment.
Thanks for the fix, @K5PTB — clean, well-scoped, and the Raspberry Pi 5 verification is exactly what I'd want to see for a multiarch path probe. The CPU/GPU utilization numbers are a nice bonus signal that QRhi actually came online.
The logic is correct on all the paths I can think of:
- Debian/Ubuntu with
dpkg-architecture(x86_64, aarch64, armhf, …): probes the right multiarch dir first, falls back to/usr/include/qt6. - Debian-like without
dpkg-architectureinstalled:DEB_HOST_MULTIARCHstays empty, the first PATHS entry becomes/usr/include//qt6which CMake normalizes harmlessly, and the/usr/include/qt6fallback still does its job. - Non-Debian: same as today — never matches, falls through to the existing "not found" diagnostic.
One optional tidy-up if you feel like it (not a blocker): only append the multiarch path when the tuple is non-empty, e.g.
set(_qt6_private_paths "/usr/include/qt6")
if(DEB_HOST_MULTIARCH)
list(PREPEND _qt6_private_paths "/usr/include/${DEB_HOST_MULTIARCH}/qt6")
endif()
find_path(DEBIAN_PRIVATE_INC
NAMES "QtGui/${Qt6_VERSION}/QtGui/private/qhighdpiscaling_p.h"
PATHS ${_qt6_private_paths}
NO_DEFAULT_PATH
)Avoids the empty-segment cosmetic, and you no longer rely on CMake collapsing //. Happy to merge as-is either way — the behavior is correct as written.
Also worth noting: this also unlocks the GPU path for armhf and i386 Debian builds for free, not just aarch64. Nice side effect.
🤖 aethersdr-agent · cost: $3.8238 · model: claude-opus-4-7
|
Claude here. Merged at 9edae4d. Pi 5 owners with This is your second clean, surgical, well-cited contribution after the SmartCAT TCP server in #3131. Both PRs share the same shape: real-world bug found while operating, root cause traced to a single line, fix is the canonical solution from the platform's own conventions ( 73, Jeremy KK7GWY & Claude (AI dev partner) |
aethersdr#3159) Fixes aethersdr#3157 ## Problem On aarch64 Debian systems (Raspberry Pi 5), the GPU spectrum renderer was silently disabled even with `qt6-base-private-dev` installed, because the fallback path probe hardcoded `x86_64-linux-gnu`: ```cmake PATHS "/usr/include/x86_64-linux-gnu/qt6" "/usr/include/qt6" ``` Qt6's private headers on aarch64 live at `/usr/include/aarch64-linux-gnu/qt6`. ## Fix Replace the hardcoded architecture string with the output of `dpkg-architecture -qDEB_HOST_MULTIARCH`, making the probe work for any Debian multiarch target. Falls back gracefully if `dpkg-architecture` is absent (non-Debian systems are unaffected — they never reached this path anyway). ## Result Confirmed on Raspberry Pi 5 / Raspberry Pi OS Trixie: - Before: `GPU spectrum rendering disabled — Qt6GuiPrivate not found` - After: `GPU spectrum rendering enabled (QRhi, Qt x.x.x)` - Observed effect: ~20% reduction in CPU utilization, ~10% increase in GPU utilization during spectrum rendering. ## Change One CMakeLists.txt hunk — adds an `execute_process(dpkg-architecture)` call and substitutes the result into the `find_path` PATHS list. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Fixes #3157
Problem
On aarch64 Debian systems (Raspberry Pi 5), the GPU spectrum renderer was silently disabled even with
qt6-base-private-devinstalled, because the fallback path probe hardcodedx86_64-linux-gnu:Qt6's private headers on aarch64 live at
/usr/include/aarch64-linux-gnu/qt6.Fix
Replace the hardcoded architecture string with the output of
dpkg-architecture -qDEB_HOST_MULTIARCH, making the probe work for any Debian multiarch target. Falls back gracefully ifdpkg-architectureis absent (non-Debian systems are unaffected — they never reached this path anyway).Result
Confirmed on Raspberry Pi 5 / Raspberry Pi OS Trixie:
GPU spectrum rendering disabled — Qt6GuiPrivate not foundGPU spectrum rendering enabled (QRhi, Qt x.x.x)Change
One CMakeLists.txt hunk — adds an
execute_process(dpkg-architecture)call and substitutes the result into thefind_pathPATHS list.🤖 Generated with Claude Code