Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 922227 - dev-libs/rocm-device-libs-5.7.1 clang can't find amdgcn/bitcode automatically
Summary: dev-libs/rocm-device-libs-5.7.1 clang can't find amdgcn/bitcode automatically
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Craig Andrews
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-01-16 15:04 UTC by Sv. Lockal
Modified: 2024-01-19 06:35 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sv. Lockal 2024-01-16 15:04:52 UTC
As designed by Clang developers, clang should be able to automatically build HIP files with a simple call. But in Gentoo build fails:

    $ touch t.hip
    $ clang -c t.hip
    clang: error: cannot find ROCm device library; provide its path via '--rocm-path' or '--rocm-device-lib-path', or pass '-nogpulib' to build without ROCm device library

This is a major headache for compiling many HIP/ROCm examples, which directly use Clang (e. g. https://github.com/amd/rocm-examples).

Candidates for directories are defined in https://github.com/llvm/llvm-project/blob/main/clang/lib/Driver/ToolChains/AMDGPU.cpp#L427 and effectively resolve to /usr/lib/clang/17/amdgcn and /usr/amdgcn (where ROCM_PATH=/usr is Gentoo replacement for ROCM_PATH=/opt/rocm).

This problem was discussed in https://bugzilla.redhat.com/show_bug.cgi?id=2209759 and they decided to store ROCm device libraries in /usr/lib/clang/17/amdgcn (see https://packages.fedoraproject.org/pkgs/rocm-device-libs/rocm-device-libs/fedora-39-updates.html)

Quick test: 
    # ln -s /usr/lib/amdgcn /usr/lib/clang/17/amdgcn

Now "clang -c t.hip" works.

I suggest to install /usr/lib/amdgcn/* to /usr/lib/clang/17/amdgcn (or `$(clang --print-resource-dir)/amdgcn` to be more precise). This will allow to remove a group of patches from existing ebuilds (search by '--rocm-path and --rocm-device-lib-path).
Comment 1 Paul Zander 2024-01-16 15:13:36 UTC
https://github.com/negril/gentoo/tree/sys-libs/libomp/fix_offload_install_location This is somewhat related
Comment 2 Sv. Lockal 2024-01-16 15:19:02 UTC
Please share your opinions. My suggestion is to move /usr/lib/amdgcn to /usr/lib/clang/17/amdgcn, and don't provide any symlinks, as they are not needed.

I think the cleanest way to do it with all dev-libs/rocm-device-libs ebuilds (but it requires to check which other ebuilds have patches for setting --rocm-path and --rocm-device-lib-path to old path).

The simpler solution is to provide a symlink in <=5.7.1, and in 6.0.0 remove the symlink. It looks that many 6.0.0 HIP/ROCm packages have hard dependency for 6.0.0 toolchain, so it should be safe.

What do you think?
Comment 3 Yiyang Wu 2024-01-19 06:35:22 UTC
(In reply to Sv. Lockal from comment #2)
> Please share your opinions. My suggestion is to move /usr/lib/amdgcn to
> /usr/lib/clang/17/amdgcn, and don't provide any symlinks, as they are not
> needed.
> 

I agree to move /usr/lib/amdgcn to /usr/lib/clang/17/amdgcn. dev-libs/rocm-device-libs is essentially part of llvm-project that somehow does not upstreamed.

> I think the cleanest way to do it with all dev-libs/rocm-device-libs ebuilds
> (but it requires to check which other ebuilds have patches for setting
> --rocm-path and --rocm-device-lib-path to old path).

Yes, that's cleaner. However, that means simultaneous revision bump of rocm-device-libs and all revdeps, which it means some user may upgrade one package, not the other one, and cause regression, so we need to set a min revision dependency for hip.


> 
> The simpler solution is to provide a symlink in <=5.7.1, and in 6.0.0 remove
> the symlink. It looks that many 6.0.0 HIP/ROCm packages have hard dependency
> for 6.0.0 toolchain, so it should be safe.

So I prefer this.