Skip to content

[HIP][Driver] --hip-link fails on Debian multiarch layout #3169

Description

@talhaHavadar

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:

  1. clang/lib/Driver/ToolChains/Linux.cpp:1126,1132-1142Linux::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.

  2. clang/lib/Driver/ToolChains/AMDGPU.cpp:467-468RocmInstallationDetector::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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions