Build mesa with -Dopencl-spirv=true to enable llvmpipe OpenCL implementation. Now run LP_CL=1 clinfo and look at the errors: === CL_PROGRAM_BUILD_LOG === <built-in>:1:10: fatal error: 'opencl-c.h' file not found This is because of the weird paths used by Gentoo's llvm slotting. rusticl (Rust OpenCL implementation) suffers from the same issue, both at runtime and at compile time.
"Weird paths". This is obviously a bug in Mesa. LLVM has CMake config files and pkgconfig files to allow it to he found.
ln -s /usr/lib/clang /usr/lib/llvm/15/lib64/clang fixes it
(In reply to darkbasic from comment #2) > ln -s /usr/lib/clang /usr/lib/llvm/15/lib64/clang fixes it This indeed allows the Mesa build to work with -Dintel-clc=enabled.
llvm@: I'm unsure what to do here. Please take a look. I'm also seeing dev-libs/intel-compute-runtime fail to build because it cannot find libopencl-clang.so.14 (which is installed to /usr/lib/llvm/14/lib64/libopencl-clang.so.14)
The paths aren't "weird". If you want to see some weird paths, try Debian: https://packages.debian.org/bullseye/amd64/libclang-common-13-dev/filelist The rough problem is that Debian is putting a lot of symlinks to let broken software build. This is not a workable approach, and we shouldn't repeat it. It only leads to people creating more broken software. Also note that the /usr/lib/clang/* path is changing in LLVM 16 (upstream) from /x.y.z to /x. Software is really expected to call `clang -print-resource-dir` to get the correct path rather than guessing.
(In reply to Michał Górny from comment #5) > The paths aren't "weird". If you want to see some weird paths, try Debian: > https://packages.debian.org/bullseye/amd64/libclang-common-13-dev/filelist > > The rough problem is that Debian is putting a lot of symlinks to let broken > software build. This is not a workable approach, and we shouldn't repeat > it. It only leads to people creating more broken software. > > Also note that the /usr/lib/clang/* path is changing in LLVM 16 (upstream) > from /x.y.z to /x. Software is really expected to call `clang > -print-resource-dir` to get the correct path rather than guessing. nobody wants to invoke clang at runtime. LLVM should just fix this mess and provide a way to get this path at _build time_.
@darkbasic mind verifying that https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19617 fixes it?
Created attachment 838695 [details, diff] bb250a9f82a6694fdbfa58f77bf9f328d8d547f5-rebased.patch
Created attachment 838697 [details, diff] b96a59a91446d89e0812bd430f0e6ffcbea3b838-rebased.patch
I had to modify your MR to apply on karolherbst/mesa.git#rusticl/si (see attached patches), but it works. Thanks!
@Matt Turner please check intel-compute-runtime, otherwise this can be closed now.
(In reply to darkbasic from comment #11) > @Matt Turner please check intel-compute-runtime, otherwise this can be > closed now. Yep, it compiles now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=9797e687d9bf332f49dc448791510e85efc20257 commit 9797e687d9bf332f49dc448791510e85efc20257 Author: Niccolò Belli <niccolo.belli@linuxsystems.it> AuthorDate: 2022-11-10 10:55:29 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2023-05-12 17:18:42 +0000 media-libs/mesa: use rusticl instead of clover This has two notable regressions: - No multilib support - No R600 support Bug: https://bugs.gentoo.org/880615 Closes: https://bugs.gentoo.org/872677 Signed-off-by: Niccolò Belli <niccolo.belli@linuxsystems.it> Signed-off-by: Matt Turner <mattst88@gentoo.org> media-libs/mesa/mesa-9999.ebuild | 32 +++++++++++++++++--------------- media-libs/mesa/metadata.xml | 2 +- profiles/arch/x86/package.use.mask | 4 ++++ profiles/features/wd40/package.use.mask | 4 ++++ 4 files changed, 26 insertions(+), 16 deletions(-)
