Summary
On Debian/Ubuntu, clang++ --hip-link -lamdhip64 fails at the linker stage with ld.lld: error: cannot open /usr/lib/libamdhip64.so: No such file or directory, because RocmInstallationDetector::detectHIPRuntime() sets LibPath = <install>/lib unconditionally and ignores the Debian multiarch subdirectory where the ROCm runtime actually lives (/usr/lib/<multiarch-triple>/libamdhip64.so). Regression relative to rocm-7.2.3.
Reproduction
On Ubuntu stonking (26.10) with libamdhip64-dev installed (libamdhip64.so shipped at /usr/lib/x86_64-linux-gnu/libamdhip64.so):
cat > /tmp/hello.hip <<'END'
#include <hip/hip_runtime.h>
int main() { return 0; }
END
clang++ -x hip --offload-arch=gfx900 /tmp/hello.hip -lamdhip64 -o /tmp/hello
Output:
ld.lld: error: cannot open /usr/lib/libamdhip64.so: No such file or directory
clang-linker-wrapper: error: 'ld.lld' failed
clang++: error: linker command failed with exit code 1
libamdhip64.so is present:
$ ls -la /usr/lib/x86_64-linux-gnu/libamdhip64*
lrwxrwxrwx /usr/lib/x86_64-linux-gnu/libamdhip64.so -> libamdhip64.so.7
lrwxrwxrwx /usr/lib/x86_64-linux-gnu/libamdhip64.so.7 -> libamdhip64.so.7.2.53211
-rwxr-xr-x /usr/lib/x86_64-linux-gnu/libamdhip64.so.7.2.53211
$ ls -la /usr/lib/libamdhip64*
(nothing)
Root cause
Two connected pieces:
-
clang/lib/Driver/ToolChains/Linux.cpp:1126,1132-1142 — Linux::addOffloadRTLibs() pushes an absolute path (<RocmInstallation->getLibPath()>/libamdhip64.so) onto the linker command line, instead of the previous -lamdhip64 form. This means ld.lld's library search path (which the Debian toolchain hook populates with /usr/lib/<multiarch>) is bypassed for this specific dependency.
-
clang/lib/Driver/ToolChains/AMDGPU.cpp:467-468 — RocmInstallationDetector::detectHIPRuntime() sets LibPath = InstallPath/lib and stops. On Debian/Ubuntu the ROCm runtime is shipped under /usr/lib/<multiarch-triple>/, so LibPath ends up pointing at a directory where the file does not exist.
Combined: the driver produces a hard-coded path (/usr/lib/libamdhip64.so) that has never been correct on Debian.
Regression window: worked in rocm-7.2.3 where the same function pushed CmdArgs.push_back(\"-lamdhip64\"); broken in rocm-7.2.14.
Impact
- Every HIP link on Debian, Ubuntu, and derivatives (Mint, PopOS, etc.) using system
libamdhip64-dev.
- Confirmed on Ubuntu 26.10 (stonking) with LLVM 23.0.0rocm7.2.14, ROCm 7.2.14 snapshot (7.2.14~git20260701.cd7668d75d).
- Non-multiarch layouts (Fedora, Arch,
/opt/rocm) are not affected — this is Debian-specific.
Suggested fix
RocmInstallationDetector already has enough context to detect multiarch. After computing LibPath, probe LibPath/<triple>/libamdhip64.so and prefer the multiarch subdir when it exists. Because the change is guarded by FS.exists(), distros without multiarch fall through to today's behavior — provably a no-op on Fedora/Arch//opt/rocm.
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -466,6 +466,15 @@ void RocmInstallationDetector::detectHIPRuntime() {
LibPath = InstallPath;
llvm::sys::path::append(LibPath, "lib");
+ // Debian multiarch: prefer <lib>/<triple> when libamdhip64.so lives
+ // there, so both the absolute path emitted by Linux::addOffloadRTLibs
+ // and the -L flag resolve to a real file. Guarded by FS.exists() so
+ // non-multiarch layouts (Fedora, Arch, /opt/rocm, etc.) fall through
+ // unchanged.
+ SmallString<0> MultiArchProbe = LibPath;
+ llvm::sys::path::append(MultiArchProbe, D.getTargetTriple(),
+ "libamdhip64.so");
+ if (FS.exists(MultiArchProbe))
+ llvm::sys::path::append(LibPath, D.getTargetTriple());
SharePath = InstallPath;
llvm::sys::path::append(SharePath, "share");
This corrects all three consumers of getLibPath():
Linux.cpp:1126 — absolute path resolves to the real file.
Linux.cpp:1148 — -L points at the correct dir.
Linux.cpp:1137 — -rpath (opt-in via -frtlib-add-rpath) also bakes the correct path.
MSVC.cpp:602 is unaffected (Windows layout doesn't use multiarch).
Environment
- Distro: Ubuntu 26.10 (stonking), amd64
- clang: 23.0.0rocm7.2.14
- Tag being built:
rocm-7.2.14 snapshot (git cd7668d75d)
- Trigger:
autopkgtest of Debian llvm-toolchain-rocm
Reported while packaging llvm-toolchain-rocm for Ubuntu. A downstream patch (debian/patches/0010-fixing-rocm-path.patch) already carries the fix — happy to send it as a PR here if useful.
Summary
On Debian/Ubuntu,
clang++ --hip-link -lamdhip64fails at the linker stage withld.lld: error: cannot open /usr/lib/libamdhip64.so: No such file or directory, becauseRocmInstallationDetector::detectHIPRuntime()setsLibPath = <install>/libunconditionally and ignores the Debian multiarch subdirectory where the ROCm runtime actually lives (/usr/lib/<multiarch-triple>/libamdhip64.so). Regression relative to rocm-7.2.3.Reproduction
On Ubuntu stonking (26.10) with
libamdhip64-devinstalled (libamdhip64.soshipped at/usr/lib/x86_64-linux-gnu/libamdhip64.so):Output:
libamdhip64.sois present:Root cause
Two connected pieces:
clang/lib/Driver/ToolChains/Linux.cpp:1126,1132-1142—Linux::addOffloadRTLibs()pushes an absolute path (<RocmInstallation->getLibPath()>/libamdhip64.so) onto the linker command line, instead of the previous-lamdhip64form. This meansld.lld's library search path (which the Debian toolchain hook populates with/usr/lib/<multiarch>) is bypassed for this specific dependency.clang/lib/Driver/ToolChains/AMDGPU.cpp:467-468—RocmInstallationDetector::detectHIPRuntime()setsLibPath = InstallPath/liband stops. On Debian/Ubuntu the ROCm runtime is shipped under/usr/lib/<multiarch-triple>/, soLibPathends up pointing at a directory where the file does not exist.Combined: the driver produces a hard-coded path (
/usr/lib/libamdhip64.so) that has never been correct on Debian.Regression window: worked in
rocm-7.2.3where the same function pushedCmdArgs.push_back(\"-lamdhip64\"); broken inrocm-7.2.14.Impact
libamdhip64-dev./opt/rocm) are not affected — this is Debian-specific.Suggested fix
RocmInstallationDetectoralready has enough context to detect multiarch. After computingLibPath, probeLibPath/<triple>/libamdhip64.soand prefer the multiarch subdir when it exists. Because the change is guarded byFS.exists(), distros without multiarch fall through to today's behavior — provably a no-op on Fedora/Arch//opt/rocm.This corrects all three consumers of
getLibPath():Linux.cpp:1126— absolute path resolves to the real file.Linux.cpp:1148—-Lpoints at the correct dir.Linux.cpp:1137—-rpath(opt-in via-frtlib-add-rpath) also bakes the correct path.MSVC.cpp:602is unaffected (Windows layout doesn't use multiarch).Environment
rocm-7.2.14snapshot (gitcd7668d75d)autopkgtestof Debianllvm-toolchain-rocmReported while packaging
llvm-toolchain-rocmfor Ubuntu. A downstream patch (debian/patches/0010-fixing-rocm-path.patch) already carries the fix — happy to send it as a PR here if useful.