I am not completely sure that is the place, but here we go. In short, I need to know the LLVM version used by rust, so I can depend on the correct clang version. (See https://bugs.gentoo.org/943397 for more information) And I would like to not have to think about the underlying version of LLVM (so, avoid using llvm-r1 and LLVM_COMPAT). Is that possible ? / Can it be made possible ? Reproducible: Always Steps to Reproduce: 1. Install rust 2. If installed, uninstall clang with the same version as the one used by LLVM in your rust install. (clang:19 for rust-bin for example) 3. Compile a rust package using ffmpeg-sys-next. (You can use media-video/wl-screenrec::GURU, otherwise you have one yourself) Actual Results: The compilation step fails when compiling ffmpeg-sys-next with the message `Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*']..."` Expected Results: The compilation succeed The main problem is, I do not want to think about the version of llvm and clang used to compile wl-screenrec. Should I have access to this information, I can depend on the correct clang version, without having to define LLVM_SLOT and inherit llvm-r1.
Isn't this sorted really by the new rust.eclass?
I could not find a variable that would give me the llvm slot, but maybe I did not look enough
Why do you need the slot? If you use rust.eclass and set RUST_NEEDS_LLVM, it'll ensure a matching LLVM is available, as long as you call llvm-r1_pkg_setup too (maybe we should have it do that for you). But ${LLVM_SLOT} will be it anyway if you *do* need it.
I need the slot, because one of the crate (ffmpeg-sys-next) need clang installed, and if the version are not the same (as in https://bugs.gentoo.org/943397) then there the compilation fails
(In reply to Gasc Henri from comment #4) > I need the slot, because one of the crate (ffmpeg-sys-next) need clang > installed, and if the version are not the same (as in > https://bugs.gentoo.org/943397) then there the compilation fails No, that doesn't mean you *need* to know the slot, it means that the matching LLVM for your Rust is installed (which is different, as the eclass needs to know it and handles it for you)? But again, what I described should work, that's why we added this..
Ah, misspoke: you do need to know the slot in order to depend on the right Clang. This should work: ``` RUST_NEEDS_LLVM=1 inherit cargo BDEPEND=" $(llvm_gen_dep ' sys-devel/clang:${LLVM_SLOT} sys-devel/llvm:${LLVM_SLOT} ') " pkg_setup() { llvm-r1_pkg_setup rust_pkg_setup } ```
Nope, it fails to source, because LLVM_COMPAT is not defined: * ERROR: pkg-test/wl-screenrec-0.1.6::localrepo failed (depend phase): * LLVM_COMPAT must be set to an array before inheriting llvm-r1 * * Call stack: * ebuild.sh, line 632: Called source '/var/db/repos/localrepo/pkg-test/wl-screenrec/wl-screenrec-0.1.6.ebuild' * wl-screenrec-0.1.6.ebuild, line 119: Called inherit 'cargo' 'shell-completion' * ebuild.sh, line 312: Called __qa_source '/var/db/repos/gentoo/eclass/cargo.eclass' * ebuild.sh, line 123: Called source '/var/db/repos/gentoo/eclass/cargo.eclass' * cargo.eclass, line 23: Called inherit 'llvm-r1' * ebuild.sh, line 312: Called __qa_source '/var/db/repos/gentoo/eclass/llvm-r1.eclass' * ebuild.sh, line 123: Called source '/var/db/repos/gentoo/eclass/llvm-r1.eclass' * llvm-r1.eclass, line 150: Called _llvm_set_globals * llvm-r1.eclass, line 107: Called die * The specific snippet of code: * die "LLVM_COMPAT must be set to an array before inheriting ${ECLASS}" * * If you need support, post the output of `emerge --info '=pkg-test/wl-screenrec-0.1.6::localrepo'`, * the complete build log and the output of `emerge -pqv '=pkg-test/wl-screenrec-0.1.6::localrepo'`. * Working directory: '/usr/lib/python3.13/site-packages' * S: '/var/tmp/portage/pkg-test/wl-screenrec-0.1.6/work/wl-screenrec-0.1.6'
Ah, you'll need to set LLVM_COMPAT=( ... ) too, and the eclass handles the intersection between that and Rust. This makes sense because we can't know ahead of time whether e.g. the thing using libclang even works with arbitrary versions of LLVM (often doesn't).
Well, that is what I wanted to avoid doing, but okay
(In reply to Gasc Henri from comment #9) > Well, that is what I wanted to avoid doing, but okay But you can't? You can't know ahead of time whether the crates that your package uses, that use libclang, work with whatever random Rust the eclass chose. How could it work? i.e. you declare in the ebuild what that crate is compatible with (as if it were written in C or C++ and using libclang), and the eclass handles the intersection between that and Rust.
If it chose "whatever LLVM Rust is built with, without specifying which LLVMs this package is okay with (because of its libclang use)", you could definitely end up with it just failing to build (and it's happened before) because of (common) LLVM API changes. The bindgen crate is especially vulnerable to this. You would have to then include the min/max versions of Rust you know work, and then that's obviously inferior to just specifying the LLVMs you tested with and know the bindgen crate bundled is compatible with.
I did not think about the LLVM API changes
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/proj/guru.git/commit/?id=30464f5d908c42afa9fb3940e3372b958063a7c5 commit 30464f5d908c42afa9fb3940e3372b958063a7c5 Author: Henri Gasc <gasc@eurecom.fr> AuthorDate: 2024-11-15 22:15:36 +0000 Commit: Henri Gasc <gasc@eurecom.fr> CommitDate: 2024-11-15 22:16:23 +0000 media-video/wl-screenrec: Add correct clang version in BDEPEND Closes: https://bugs.gentoo.org/943557 Signed-off-by: Henri Gasc <gasc@eurecom.fr> ...screenrec-0.1.6.ebuild => wl-screenrec-0.1.6-r1.ebuild} | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-)
