For some (historical?) reasons, sys-libs/libomp only supports the latest available LLVM. If we have multiple LLVM instances, it is not possible to have specific versions of libomp bound to their corresponding LLVM counterpart. This causes headaches especially when dealing with AMD/ROCm stuff. At date of writing, LLVM 16 is available while AMD/ROCm only supports LLVM 15 (see various ebuild). Thus, when enabling GPU offloading with sys-libs/libomp, the various files are compiled with Clang/LLVM16 which leads to protests: /usr/lib/llvm/15/bin/clang++ --rocm-device-lib-path=/usr/lib/amdgcn/bitcode --libomptarget-amdgpu-bc-path="/usr/lib64" -fopenmp -fopenmp-targets=amdgcn-amd-amdhsa -x c openmp_offload.c fatal error: cannot open file '/usr/lib64/libomptarget-amdgpu-gfx1031.bc': Unknown attribute kind (86) (Producer: 'LLVM16.0.1' Reader: 'LLVM 15.0.7') Various other ebuilds related to LLVM/Clang are slotted but not this one.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=2836fd63ef7c7b8756883bffd58e06392653f65d commit 2836fd63ef7c7b8756883bffd58e06392653f65d Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-03-16 16:52:50 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-03-16 17:08:51 +0000 sys-libs/libomp: Add slotted versions Closes: https://bugs.gentoo.org/904140 Signed-off-by: Michał Górny <mgorny@gentoo.org> sys-libs/libomp/libomp-15.0.7-r7.ebuild | 135 +++++++++++++++++ sys-libs/libomp/libomp-16.0.6-r1.ebuild | 153 +++++++++++++++++++ sys-libs/libomp/libomp-17.0.6-r1.ebuild | 153 +++++++++++++++++++ sys-libs/libomp/libomp-18.1.0-r1.ebuild | 163 +++++++++++++++++++++ sys-libs/libomp/libomp-19.0.0.9999.ebuild | 4 +- .../libomp/libomp-19.0.0_pre20240316-r1.ebuild | 162 ++++++++++++++++++++ 6 files changed, 769 insertions(+), 1 deletion(-)
I tried this, upgrading from slot0 to slot18 followed by a toolchain rebuild, then a world rebuild. Every package that uses tc-check-openmp in pkg_pretend() fails to find it, and if I remove the check from the ebuild, openmp is not found during src_configure(). Am I missing something ?
I'm seeing the same issue - openmp support is no longer found after this change... with Clang/libc++ as system compiler, that is.
Please file a new bug and/or let's discuss it on #gentoo-llvm then.
https://bugs.gentoo.org/927249
Reverting.
Running into this issue right now when trying to install clang 20. I am using AMD-ROCm 6.3.3 and as a result I have both LLVM 19 and 20 installed, but need clang 20 for something else. Because I have the `openmp` USE flag set, `llvm-core/clang-runtime` pulls in `llvm-runtime/openmp`, but since I have `llvm-runtimes/offload-19*` installed, it won't upgrade to 20, and it's unslotted. Can `llvm-runtime/openmp` be slotted like the rest of the LLVM and Clang packages? Happy to help if there's anything I can do. Thanks. ``` $ sudo emerge -av --backtrack=30 llvm-core/clang:20 These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 9.55 s (backtrack: 5/30). [ebuild U ~] llvm-runtimes/openmp-20.1.3:0/20.1::gentoo [19.1.7:0/19.1::gentoo] USE="verify-sig -debug -gdb-plugin -hwloc -ompt -test" ABI_X86="32 (64) (-x32)" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" 0 KiB [ebuild U ~] llvm-core/clang-common-20.1.3::gentoo [19.1.7::gentoo] USE="cet verify-sig -bootstrap-prefix -default-compiler-rt -default-libcxx -default-lld -hardened -llvm-libunwind" 0 KiB [ebuild NS ~] llvm-core/clang-20.1.3:20/20.1::gentoo [19.1.7:19/19.1::gentoo] USE="extra (pie) static-analyzer verify-sig xml -debug -doc (-ieee-long-double) -test" ABI_X86="32 (64) (-x32)" LLVM_TARGETS="(AArch64) (AMDGPU) (ARM) (AVR) (BPF) (Hexagon) (Lanai) (LoongArch) (MSP430) (Mips) (NVPTX) (PowerPC) (RISCV) (Sparc) (SystemZ) (VE) (WebAssembly) (X86) (XCore) -ARC -CSKY -DirectX -M68k -SPIRV -Xtensa" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" 0 KiB [ebuild NS ~] llvm-core/clang-toolchain-symlinks-20:20::gentoo [19:19::gentoo] USE="native-symlinks -gcc-symlinks -multilib-symlinks" 0 KiB [ebuild NS ~] llvm-runtimes/compiler-rt-20.1.3:20::gentoo [19.1.7:19::gentoo] USE="atomic-builtins (clang) verify-sig -debug -test" ABI_X86="32 (64)" 0 KiB [ebuild NS ~] llvm-runtimes/compiler-rt-sanitizers-20.1.3:20::gentoo [19.1.7:19::gentoo] USE="asan cfi (clang) ctx-profile dfsan gwp-asan hwasan libfuzzer lsan memprof msan nsan%* orc profile rtsan%* safestack scudo tsan ubsan verify-sig xray -debug (-shadowcallstack) -test" ABI_X86="32 (64)" 0 KiB [ebuild NS ~] llvm-core/clang-runtime-20.1.3:20::gentoo [19.1.7:19::gentoo] USE="compiler-rt openmp sanitize -default-compiler-rt% -default-libcxx% -default-lld% -libcxx -llvm-libunwind% -offload* -polly%" ABI_X86="32 (64) (-x32)" 0 KiB Total: 7 packages (2 upgrades, 5 in new slots), Size of downloads: 0 KiB !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: llvm-runtimes/openmp:0 (llvm-runtimes/openmp-20.1.3:0/20.1::gentoo, ebuild scheduled for merge) USE="verify-sig -debug -gdb-plugin -hwloc -ompt -test" ABI_X86="32 (64) (-x32)" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" pulled in by >=llvm-runtimes/openmp-20.1.3[abi_x86_32(-)?,abi_x86_64(-)?,abi_x86_x32(-)?,abi_mips_n32(-)?,abi_mips_n64(-)?,abi_mips_o32(-)?,abi_s390_32(-)?,abi_s390_64(-)?] required by (llvm-core/clang-runtime-20.1.3:20/20::gentoo, ebuild scheduled for merge) USE="compiler-rt openmp sanitize -default-compiler-rt -default-libcxx -default-lld -libcxx -llvm-libunwind -offload -polly" ABI_X86="32 (64) (-x32)" ^^ ^^^^^^ (llvm-runtimes/openmp-19.1.7:0/19.1::gentoo, installed) USE="verify-sig -debug -gdb-plugin -hwloc -ompt -test" ABI_X86="32 (64) (-x32)" PYTHON_SINGLE_TARGET="python3_12 -python3_10 -python3_11 -python3_13" pulled in by ~llvm-runtimes/openmp-19.1.7[ompt?] required by (llvm-runtimes/offload-19.1.7:0/19.1::gentoo, installed) USE="debug verify-sig -ompt -test" ABI_X86="(64)" LLVM_TARGETS="(-AMDGPU) -NVPTX" ^ ^^^^^^ It may be possible to solve this problem by using package.mask to prevent one of those packages from being selected. However, it is also possible that conflicting dependencies exist such that they are impossible to satisfy simultaneously. If such a conflict exists in the dependencies of two different packages, then those packages can not be installed simultaneously. For more information, see MASKED PACKAGES section in the emerge man page or refer to the Gentoo Handbook. ```
