mesa fail configuring even with llvm is present. >>> Emerging (1 of 1) media-libs/mesa-23.1.3::gentoo * mesa-23.1.3.tar.xz BLAKE2B SHA512 size ;-) ... [ ok ] * Determining the location of the kernel source code * Found kernel source directory: * /usr/src/linux * Found sources for kernel version: * 6.1.31-gentoo * Checking for suitable kernel configuration options ... [ ok ] * Checking whether python3_12 is suitable ... * >=dev-lang/python-3.12.0_beta3:3.12 ... [ !! ] * Checking whether python3_11 is suitable ... * >=dev-lang/python-3.11.4:3.11 ... [ ok ] * python_check_deps ... * >=dev-python/mako-0.8.0[python_targets_python3_11(-)] ... [ ok ] * dev-python/ply[python_targets_python3_11(-)] ... [ ok ] * Using python3.11 to build (via PYTHON_COMPAT iteration) >>> Unpacking source... >>> Unpacking mesa-23.1.3.tar.xz to /var/tmp/portage/media-libs/mesa-23.1.3/work >>> Source unpacked in /var/tmp/portage/media-libs/mesa-23.1.3/work >>> Preparing source in /var/tmp/portage/media-libs/mesa-23.1.3/work/mesa-23.1.3 ... * Applying clang_resource_dir.patch ... [ ok ] >>> Source prepared. >>> Configuring source in /var/tmp/portage/media-libs/mesa-23.1.3/work/mesa-23.1.3 ... * 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! * * Call stack: * ebuild.sh, line 136: Called src_configure * environment, line 3876: Called meson-multilib_src_configure * environment, line 2515: Called multilib-minimal_src_configure * environment, line 2725: Called multilib_foreach_abi 'multilib-minimal_abi_src_configure' * environment, line 2975: Called multibuild_foreach_variant '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2680: Called _multibuild_run '_multilib_multibuild_wrapper' 'multilib-minimal_abi_src_configure' * environment, line 2678: Called _multilib_multibuild_wrapper 'multilib-minimal_abi_src_configure' * environment, line 796: Called multilib-minimal_abi_src_configure * environment, line 2719: Called multilib_src_configure * environment, line 3274: Called get_llvm_prefix * environment, line 2024: Called get_llvm_slot * environment, line 2064: Called die * The specific snippet of code: * die "No LLVM slot${1:+ <= ${1}} satisfying the package's dependencies found installed!" * * If you need support, post the output of `emerge --info '=media-libs/mesa-23.1.3::gentoo'`, * the complete build log and the output of `emerge -pqv '=media-libs/mesa-23.1.3::gentoo'`. * The complete build log is located at '/var/tmp/portage/media-libs/mesa-23.1.3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-libs/mesa-23.1.3/temp/environment'. * Working directory: '/var/tmp/portage/media-libs/mesa-23.1.3/work/mesa-23.1.3-abi_x86_32.x86' * S: '/var/tmp/portage/media-libs/mesa-23.1.3/work/mesa-23.1.3' Reproducible: Always Steps to Reproduce: 1. emerge mesa Portage 3.0.49 (python 3.11.4-final-0, default/linux/amd64/17.1, gcc-12, glibc-2.37-r3, 6.1.31-gentoo x86_64) ================================================================= System uname: Linux-6.1.31-gentoo-x86_64-Intel-R-_Core-TM-_i5-8350U_CPU_@_1.70GHz-with-glibc2.37 KiB Mem: 16142552 total, 7904680 free KiB Swap: 0 total, 0 free Timestamp of repository gentoo: Sun, 16 Jul 2023 06:00:01 +0000 Head commit of repository gentoo: 5abe4ff8e90e079ea2a34969220ca0fd8eb4bdbf sh bash 5.1_p16-r6 ld GNU ld (Gentoo 2.39 p6) 2.39.0 app-misc/pax-utils: 1.3.5::gentoo app-shells/bash: 5.1_p16-r6::gentoo dev-java/java-config: 2.3.1-r1::gentoo dev-lang/perl: 5.36.1-r3::gentoo dev-lang/python: 2.7.18_p16-r1::gentoo, 3.8.16_p2::gentoo, 3.9.16_p3::gentoo, 3.10.12::gentoo, 3.11.4::gentoo dev-lang/rust-bin: 1.69.0-r1::gentoo dev-util/cmake: 3.26.4-r1::gentoo dev-util/meson: 1.1.1::gentoo sys-apps/baselayout: 2.13-r1::gentoo sys-apps/openrc: 0.46::gentoo sys-apps/sandbox: 2.32::gentoo sys-devel/autoconf: 2.13-r7::gentoo, 2.69-r5::gentoo, 2.71-r6::gentoo sys-devel/automake: 1.16.5::gentoo sys-devel/binutils: 2.36.1-r2::gentoo, 2.37_p1-r2::gentoo, 2.38-r2::gentoo, 2.39-r5::gentoo, 2.40-r5::gentoo sys-devel/binutils-config: 5.5::gentoo sys-devel/clang: 15.0.7-r3::gentoo, 16.0.6::gentoo sys-devel/gcc: 10.4.1_p20230426-r1::gentoo, 11.3.1_p20230427::gentoo, 12.3.1_p20230526::gentoo sys-devel/gcc-config: 2.11::gentoo sys-devel/libtool: 2.4.7-r1::gentoo sys-devel/llvm: 15.0.7-r3::gentoo, 16.0.6::gentoo sys-devel/make: 4.4.1-r1::gentoo sys-kernel/linux-headers: 6.1::gentoo (virtual/os-headers) sys-libs/glibc: 2.37-r3::gentoo Repositories: gentoo location: /usr/portage sync-type: rsync sync-uri: rsync://rsync.gentoo.org/gentoo-portage priority: -1000 volatile: True sync-rsync-verify-jobs: 1 sync-rsync-verify-max-age: 24 sync-rsync-verify-metamanifest: yes sync-rsync-extra-opts: montjoie location: /usr/local/portage masters: gentoo priority: 0 volatile: True ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="@FREE google-chrome freedist linux-firmware no-source-code bh-luxi linux-fw-redistributable xgraph JSON XMAME unRAR" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo" CXXFLAGS="-O2 -pipe" DISTDIR="/usr/portage/distfiles" ENV_UNSET="CARGO_HOME DBUS_SESSION_BUS_ADDRESS DISPLAY GDK_PIXBUF_MODULE_FILE GOBIN GOPATH PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR XDG_STATE_HOME" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs buildpkg-live config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned qa-unresolved-soname-deps sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LANG="fr_FR.UTF-8" LC_ALL="fr_FR.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" LEX="flex" MAKEOPTS="-j8" PKGDIR="/usr/portage/packages" PORTAGE_BINHOST="http://192.168.1.40:82/x86_64/" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git" PORTAGE_TMPDIR="/var/tmp" SHELL="/bin/bash" USE="X alsa amd64 bzip2 caps cli crypt dri dri3 glamor iconv ipv6 jpeg libtirpc mp3 multilib ncurses nptl opengl overlay pam pcre png readline seccomp split-usr ssl test-rust unicode vaapi vdpau verify-sig xattr xvmc zlib" ABI_X86="64" ADA_TARGET="gnat_2021" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_X86="mmx sse sse2 mmxext avx sse4_1 sse4_2 ssse3 sse3 avx2 aes fma f16c" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock greis isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="efi-32 efi-64 pc" INPUT_DEVICES="libinput keyboard mouse synaptics" KERNEL="linux" L10N="fr en-GB uk" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LLVM_TARGETS="AArch64 ARM BPF NVPTX" LUA_SINGLE_TARGET="lua5-1" LUA_TARGETS="lua5-1" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php8-1" POSTGRES_TARGETS="postgres12 postgres13" PYTHON_SINGLE_TARGET="python3_11" PYTHON_TARGETS="python3_10 python3_11" QEMU_SOFTMMU_TARGETS="x86_64 riscv64" RUBY_TARGETS="ruby31" VIDEO_CARDS="intel vesa i965" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq proto steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: ADDR2LINE, AR, ARFLAGS, AS, ASFLAGS, CC, CCLD, CONFIG_SHELL, CPP, CPPFLAGS, CTARGET, CXX, CXXFILT, ELFEDIT, EMERGE_DEFAULT_OPTS, EXTRA_ECONF, F77FLAGS, FC, GCOV, GPROF, INSTALL_MASK, LD, LFLAGS, LIBTOOL, LINGUAS, MAKE, MAKEFLAGS, NM, OBJCOPY, OBJDUMP, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, RANLIB, READELF, RUSTFLAGS, SIZE, STRINGS, STRIP, YACC, YFLAGS
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.
