| Summary: | media-libs/mesa-23.1.3: No LLVM slot satisfying the package's dependencies found installed! | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | LABBE Corentin <clabbe.montjoie> |
| Component: | Current packages | Assignee: | Gentoo X packagers <x11> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dflogeras2, jeremy.william.murphy, mattst88, ngg |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build.log
environment |
||
|
Description
LABBE Corentin
2023-07-16 17:42:12 UTC
Please can you attach the full build log from var/tmp/portage/media-libs/mesa-23.1.3/temp/build.log and environment from /var/tmp/portage/media-libs/mesa-23.1.3/temp/environment Also output of emerge -pv media-libs/mesa Thank you Alternatively, you might get this resolved easier by joining us in #gentoo on IRC at irc.libera.chat and sharing this bug so we can help investigate. I'm on a stable setup with much the same environment as you that I can see and Mesa builds fine. Judging from your output * abi_x86_32.x86: running multilib-minimal_abi_src_configure * ERROR: media-libs/mesa-23.1.3::gentoo failed (configure phase): * No LLVM slot satisfying the package's dependencies found installed! you've got the same problem as me, i. e. your llvm isn't built with 32bit support. Adding sys-devel/llvm abi_x86_32 sys-devel/clang abi_x86_32 to /etc/portage/package.use/* fixes this. This is not related to abi32 since I have a working host which build fine mesa without it: [ebuild R ] sys-devel/llvm-16.0.6:16::gentoo USE="binutils-plugin libffi ncurses verify-sig -debug -doc -exegesis -libedit -test -xar -xml -z3 -zstd" ABI_X86="(64) -32 (-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)" 0 KiB [ebuild R ] media-libs/mesa-23.1.3::gentoo USE="X gles1 gles2 lm-sensors osmesa proprietary-codecs vaapi vdpau xa zstd -d3d9 -debug -llvm -opencl (-selinux) -test -unwind -valgrind -vulkan -vulkan-overlay -wayland -zink" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" VIDEO_CARDS="-d3d12 (-freedreno) -intel -lavapipe (-lima) -nouveau (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware" 0 KiB [ebuild R ] sys-devel/clang-16.0.6:16::gentoo USE="extra (pie) static-analyzer verify-sig -debug -doc (-ieee-long-double) -test -xml" ABI_X86="(64) -32 (-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_11 -python3_10 (-python3_12)" 0 KiB On the problematic host I have: [ebuild U ] media-libs/mesa-23.1.3::gentoo [23.0.3-r1::gentoo] USE="X gles2 proprietary-codecs vaapi vdpau vulkan zstd -d3d9 -debug -gles1 -llvm -lm-sensors -opencl -osmesa (-selinux) -test -unwind -valgrind -vulkan-overlay -wayland -xa -zink" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="sse2" VIDEO_CARDS="intel -d3d12 (-freedreno) -lavapipe% (-lima) -nouveau (-panfrost) -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware" 0 KiB [ebuild R ] sys-devel/llvm-16.0.6:16::gentoo USE="binutils-plugin libffi ncurses verify-sig -debug -doc -exegesis -libedit -test -xar -xml -z3 -zstd" ABI_X86="(64) -32 (-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)" 255 KiB [ebuild R ] sys-devel/clang-16.0.6:16::gentoo USE="extra (pie) static-analyzer verify-sig -debug -doc (-ieee-long-double) -test -xml" ABI_X86="(64) -32 (-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_11 -python3_10 (-python3_12)" 0 KiB Anyway llvm/clang are identic on both host (I use binary package) Created attachment 865631 [details]
build.log
Created attachment 865632 [details]
environment
It seems (to my untrained eye) that mesa-23 now hard requires llvm_targets_AMDGPU, and Labbe (and myself) have done what we were warned against: (from profiles/base/package.use.force) "# Enable all LLVM targets unconditionally. Unfortunately, disabling # targets tend to break reverse dependencies (e.g. Rust) and we are yet # to find a clean way of resolving that. Compared to the damage # potential, the increase of build time is a minor problem. Users who # really insist of building a smaller system can un-force the flags # at their own responsibility. See bug #767700." The only system I have that mesa-23 compiled successfully is an AMDGPU based one. Maybe this is an oversight, or maybe we're just in the territory of "you can't fight city hall" (In reply to David Flogeras from comment #6) > It seems (to my untrained eye) that mesa-23 now hard requires > llvm_targets_AMDGPU, and Labbe (and myself) have done what we were warned > against: > > (from profiles/base/package.use.force) > "# Enable all LLVM targets unconditionally. Unfortunately, disabling > # targets tend to break reverse dependencies (e.g. Rust) and we are yet > # to find a clean way of resolving that. Compared to the damage > # potential, the increase of build time is a minor problem. Users who > # really insist of building a smaller system can un-force the flags > # at their own responsibility. See bug #767700." > > The only system I have that mesa-23 compiled successfully is an AMDGPU based > one. Maybe this is an oversight, or maybe we're just in the territory of > "you can't fight city hall" All my clang/llvm have amdgpu so it is not that. I'm confused by this line then (from comment 1) LLVM_TARGETS="AArch64 ARM BPF NVPTX" I'm even more confused by on my system when I type emerge --info, I do not get a LLVM_TARGETS line. Ahh, I think I see the common thing on both your working/non-working system and mine.
It seems USE="-llvm vulkan" is breaking things. On my broken system (and yours) we have USE="-llvm vulkan". On my working system I have USE="llvm vulkan" and on your working system you have USE="-llvm -vulkan"
It seems starting on line 399 of the ebuild:
if use vulkan && use video_cards_intel; then
PKG_CONFIG_PATH="$(get_llvm_prefix)/$(get_libdir)/pkgconfig"
emesonargs+=($(meson_feature llvm intel-clc))
fi
It gets in here with USE="-llvm vulkan" (and intel), but get_llvm_prefix fails, because the variables it needs were never set up. As a test I changed it to:
if use llvm && use vulkan && use video_cards_intel; then
And it configures and compiles, but I don't want to blindly install this in case it breaks my system.
I'm not sure of the correct fix, either vulkan+intel requires llvm and should be enforced, or it doesn't and should skip this check. Guess we'll have to wait for a dev to weigh in.
I confirm removing vulkan lead to build. Also hitting this with USE="-llvm vulkan" VIDEO_CARDS="intel". I have had this issue for months now and have been doing similar to what you suggested below. Haven't had any issues yet. Is there something other than this bug report we need to do to have a dev check it out? Should a pull request be made with the change below to get the ball rolling? Thanks. (In reply to David Flogeras from comment #9) > Ahh, I think I see the common thing on both your working/non-working system > and mine. > > It seems USE="-llvm vulkan" is breaking things. On my broken system (and > yours) we have USE="-llvm vulkan". On my working system I have USE="llvm > vulkan" and on your working system you have USE="-llvm -vulkan" > > It seems starting on line 399 of the ebuild: > if use vulkan && use video_cards_intel; then > PKG_CONFIG_PATH="$(get_llvm_prefix)/$(get_libdir)/pkgconfig" > emesonargs+=($(meson_feature llvm intel-clc)) > fi > > > It gets in here with USE="-llvm vulkan" (and intel), but get_llvm_prefix > fails, because the variables it needs were never set up. As a test I changed > it to: > > if use llvm && use vulkan && use video_cards_intel; then > > And it configures and compiles, but I don't want to blindly install this in > case it breaks my system. > > I'm not sure of the correct fix, either vulkan+intel requires llvm and > should be enforced, or it doesn't and should skip this check. Guess we'll > have to wait for a dev to weigh in. I'm hitting the same issue (with the -llvm vulkan intel combination), it seems to be caused by this commit: https://github.com/gentoo/gentoo/commit/5d184b31cc80996fed4b938fc2b3e68e27b1e29c (CC @mattst88). Can someone check why llvm_check_deps() is failing? E.g. by editing the ebuild and commenting out the has_version statements one by one and retesting. (In reply to Matt Turner from comment #14) > Can someone check why llvm_check_deps() is failing? E.g. by editing the > ebuild and commenting out the has_version statements one by one and > retesting. I am also affected by this bug, since I am compiling for a Cherry Trail Intel Atom system. Commenting out the has_version line for sys-devel/llvm (line 200) has resulted in the compilation process resuming and finishing with no errors. Note that I am not an expert, but I would maybe think that it has to do something with the fact that it tries to look up LLVM_USE_DEPS="llvm_targets_AMDGPU(+)", which of course, if you have Intel and used use.force to disable all except X86 returns false, breaking the compilation process and erroring out. (In reply to krpisjar from comment #15) > (In reply to Matt Turner from comment #14) > > Can someone check why llvm_check_deps() is failing? E.g. by editing the > > ebuild and commenting out the has_version statements one by one and > > retesting. > > I am also affected by this bug, since I am compiling for a Cherry Trail > Intel Atom system. Commenting out the has_version line for sys-devel/llvm > (line 200) has resulted in the compilation process resuming and finishing > with no errors. Note that I am not an expert, but I would maybe think that > it has to do something with the fact that it tries to look up > LLVM_USE_DEPS="llvm_targets_AMDGPU(+)", which of course, if you have Intel > and used use.force to disable all except X86 returns false, breaking the > compilation process and erroring out. Which I guess is further supported by the fact that if I remove [${LLVM_USE_DEPS}] it compiles fine with no errors as well. Have you overridden the profile settings to disable LLVM_TARGETS=AMDGPU? If so, you've broken it so you get to keep the pieces. (In reply to Matt Turner from comment #17) > Have you overridden the profile settings to disable LLVM_TARGETS=AMDGPU? > > If so, you've broken it so you get to keep the pieces. Yeah, I did. The only target I have enabled is X86 (don't ask me, just felt the need to tweak whilst it has probably no benefit whatsoever), so I'll just keep the pieces to myself. Point being: if llvm_targets_AMDGPU is unset, it will break, which is probably what causes the others to error out as well. Yes, thank you very much for checking! I'll wait to see if anyone else has a different cause before closing the bug. I also confirm that I have removed all (what I thought) were unnecessary LLVM targets to save time/space. Forgive my ignorance, but why is AMDGPU required to build mesa for non-amdgpu setups? (In reply to David Flogeras from comment #20) > I also confirm that I have removed all (what I thought) were unnecessary > LLVM targets to save time/space. The mask message does explain why it's forced on. (In reply to David Flogeras from comment #20) > Forgive my ignorance, but why is AMDGPU required to build mesa for > non-amdgpu setups? It's because depending on LLVM is a nightmare, so requiring LLVM_TARGETS=AMDGPU optionally massively complicates things. commit 6c4bdcbd3b25bdc3b4ccd6ab7d839840dbbef813 Author: Matt Turner <mattst88@gentoo.org> Date: Thu May 11 16:04:14 2023 -0400 media-libs/mesa: Simplify LLVM dependencies Specifically, just always require that sys-devel/llvm (or sys-devel/clang) is built with LLVM_TARGETS=AMDGPU. It's been in package.use.force since llvm:13 and seems unlikely to be removed. It also massively simplifies the dependencies. Signed-off-by: Matt Turner <mattst88@gentoo.org> Got it, and I agree. However, I still wonder if llvm is required for intel? See comment #9 for my test case. I am trying to build -llvm +vulkan, and it seems (again to my untrained eye) that the LLVM deps slipped thru the cracks for that if it is a valid combination. (In reply to David Flogeras from comment #23) > Got it, and I agree. > > However, I still wonder if llvm is required for intel? See comment #9 for > my test case. I am trying to build -llvm +vulkan, and it seems (again to my > untrained eye) that the LLVM deps slipped thru the cracks for that if it is > a valid combination. No, LLVM is not required for Intel. On Intel there are only two cases where it's added as a dependency: 1. the Rusticl OpenCL implementation 2. Vulkan raytracing support (for upcoming hardware) Feel free to disable llvm support if you don't need either of these features. (In reply to Matt Turner from comment #24) > (In reply to David Flogeras from comment #23) > > Got it, and I agree. > > > > However, I still wonder if llvm is required for intel? See comment #9 for > > my test case. I am trying to build -llvm +vulkan, and it seems (again to my > > untrained eye) that the LLVM deps slipped thru the cracks for that if it is > > a valid combination. > > No, LLVM is not required for Intel. > > On Intel there are only two cases where it's added as a dependency: > > 1. the Rusticl OpenCL implementation > 2. Vulkan raytracing support (for upcoming hardware) > > Feel free to disable llvm support if you don't need either of these features. Please fix the ebuild to allow us to do so. As it was mentioned in multiple comments (#9, #13, #23), the "-llvm +vulkan" use flag combination does not compile on intel currently. That's because this new ray tracing support tries to pull in llvm-related dependencies even if the llvm flag is disabled. (This is precisely why mixing different issues in the same bug is not great.) (In reply to Sam James from comment #26) > (This is precisely why mixing different issues in the same bug is not great.) It can be seen in #comment 3 that the original bug report is using the "-llvm vulkan" combination as well, I don't think these are different issues. It is, because we've got people complaining about it who have LLVM but with different targets enabled - who wouldn't have hit it otherwise. But your issue can be hit when LLVM isn't installed at all and none of its functionality is desired. Same root reason, but one of them is a case nobody really cares about, and the other (yours) is one we care about. (In reply to Sam James from comment #28) > It is, because we've got people complaining about it who have LLVM but with > different targets enabled - who wouldn't have hit it otherwise. > > But your issue can be hit when LLVM isn't installed at all and none of its > functionality is desired. > > Same root reason, but one of them is a case nobody really cares about, and > the other (yours) is one we care about. You're right. However, if the "-llvm vulkan" combination is fixed and it does not trt to use llvm at all, those strange cases will most probably start to work as well (as long as they specify "-llvm"). Thanks for pointing that out. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=00223287044785f94cdc91927c4fc14bf9ae880a commit 00223287044785f94cdc91927c4fc14bf9ae880a Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-08-28 15:09:39 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-08-28 15:11:08 +0000 media-libs/mesa: Fix build without LLVM Closes: https://bugs.gentoo.org/910435 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-23.1.6.ebuild | 6 ++++-- media-libs/mesa/mesa-9999.ebuild | 6 ++++-- 2 files changed, 8 insertions(+), 4 deletions(-) (In reply to Matt Turner from comment #30) > Thanks for pointing that out. It's still not working without LLVM, because RDEPEND pulls in libclc (which requires LLVM) even if "-llvm" is used. I think those dependencies can be moved to the "llvm?" part to solve this as they don't seem to be needed. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0486dbce0557666174b0c157f4f5b14adc64e007 commit 0486dbce0557666174b0c157f4f5b14adc64e007 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-08-29 13:22:26 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-08-29 13:23:21 +0000 media-libs/mesa: Put raytracing deps behind USE=llvm Bug: https://bugs.gentoo.org/910435 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-23.1.6.ebuild | 12 +++++++----- media-libs/mesa/mesa-9999.ebuild | 14 ++++++++------ 2 files changed, 15 insertions(+), 11 deletions(-) I think you modified unrelated dependencies in the latest commit. Please take a look at it. (In reply to ngg from comment #34) > I think you modified unrelated dependencies in the latest commit. Please > take a look at it. Please be more specific. Do you mean the PYTHON_COMPAT part or something else? (In reply to Sam James from comment #35) > (In reply to ngg from comment #34) > > I think you modified unrelated dependencies in the latest commit. Please > > take a look at it. > > Please be more specific. Do you mean the PYTHON_COMPAT part or something > else? I think that the wrong deps were moved into an "llvm?" block, e.g. the dev-python/ply package is now only referenced as a dependency if llvm is used, however in the python_check_deps() function it is used even without the llvm flag. On the other side, the dev-libs/libclc dependency is still used even without the llvm flag, but that is the one that should have been moved to an "llvm?" block as far as I can see (because the "-Dintel-clc=enabled" is only set if llvm is used and also because libclc itself depends on llvm). The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=75efa513eb6d609f9d849f0e59c125e377bdcd80 commit 75efa513eb6d609f9d849f0e59c125e377bdcd80 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2023-08-29 20:21:13 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-08-29 20:22:11 +0000 media-libs/mesa: Conditionalize ply check with 'use llvm' Missed in 0486dbce0557 ("media-libs/mesa: Put raytracing deps behind USE=llvm"). Bug: https://bugs.gentoo.org/910435 Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-23.1.6.ebuild | 2 +- media-libs/mesa/mesa-9999.ebuild | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) Thank you for noticing so many bugs. Now, let's stop using this bug report. Please file a separate bug if you find something else. |
