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
