Hi Christian, On 2025-10-19 14:27, Christian Kastner wrote:
The recent update of hipcc to 7.0.1+dfsg-1 in unstable made src:ggml
FTBFS because its d/rules contains
export HIPCXX=clang-17
I looked at two other samples of `build-rdeps hipcc`, ectrans and spfft,
and they use the same pattern, so this will affect them, too.
Thank you for the report. The backing clang for hipcc will change regularly. If packages refer to a specific version of clang in their d/rules, they will need to add clang-<N> and rocm-device-libs-<N> to their B-D (where <N> is the version of clang that they are specifying).
I must apologize for not directing reverse dependencies to do that previously. When we'd begun using that pattern, I hadn't fully appreciated the effects that package updates would have or what mitigations we might have by the time we were moving to a new backing compiler.
rocm-hipamd 5.7.1 makes this same mistake in its autopkgtests as the build-rdeps that you list. Those failed autopkgtests are also blocking the migration of rocm-llvm to testing. I would prepare a rocm-hipamd 5.7.1-8 and fix the tests by adding clang-17 and rocm-device-libs-17 to d/t/control, but rocm-hipamd also FTBFS due to the libamd-comgr-dev transition. I will finish the libamd-comgr3 transition by updating rocm-hipamd to 6.4.4, and continuing the transition from libamdhip64-5 to libamdhip64-6 and then close this bug. The problem is not in rocm-llvm, but rather is a mistake in the reverse dependencies. Their packaging rules should not directly reference a transitive dependency; if they need to reference the clang compiler directly they should be adding it directly to their B-D.
Nothing about hipcc 7.0.1+dfsg-1 prevents users from building with clang-17 as their HIPCXX compiler. Users just need to be sure they've installed clang-17 and rocm-device-libs-17, as that won't happen automatically.
With the understanding that a decision has been made against a
/usr/bin/hipcxx, a workaround would be to ship this in some private
directory of hipcc, for example
/usr/lib/hipcc/bin/clang -> /usr/bin/clang-xx
where xx is the version of clang that this particular hipcc needs.
That's a reasonable future convention to solve this problem more cleanly, albeit one of a few in discussion.
Sincerely, Cory Bloor