Linking fails with 'ld.lld: error: Invalid summary version 10. Version should be in the range [1-9]' This seems to be the same problem as this commit fixes https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=ce974137d6318c4ebc3321558be253842a72a5e4 One fix may be "Switch to dev-lang/rust[system-llvm], which will guarantee a matching version." If so, when LTO is enabled, this may affect other software, so LLVM and Rust must be matched to prevent this. chromium-130.0.6723.58 LLVM version 19.1.2 rust 1.82.0
Build log please. The ebuild should already be enforcing this so I'm wondering where this is going wrong.
And emerge --info; can't forget that.
Some musings to myself in IRC: If we selected LLVM slot 19, `llvm_prepend_path "${LLVM_SLOT}"` should ensure that `lld 19 is the first thing available in ${PATH} when `ld.lld` is executed. We make sure via `has_version "sys-devel/lld:${slot}"` in the `chromium_pick_llvm_slot()` call that a given slot is installed, so if lld:19 wasn't there it should fail and fall back to a different slot. The check for `has_version "virtual/rust:0/llvm-${slot}"` should ensure that there _is_ an appropriate Rust for that LLVM slot (19 is 1.82). So how did we end up in this position? If this is consistent we can instrument the ebuild to get a bit of a better idea why this happens. Anyway, no more debugging until we have actual logs / evidence.
Created attachment 907313 [details] emerge --info '=www-client/chromium-130.0.6723.58::gentoo' emerge --info =www-client/chromium-130.0.6723.58::gentoo Note I modified the use setting system-toolchain, but that did not change anything
Created attachment 907314 [details] build log Build log (.zip compressed) Same use flag changed between the initial report
Created attachment 907315 [details] emerge --info output
Created attachment 907317 [details] version of chromium that did successfully compile Screenshot of the version in use now that did compile ok
I noticed that both the rust and rust-bin are installed. Should that happen?
eselect rust list gives: Available Rust versions: [1] rust-bin-1.81.0 [2] rust-1.82.0 *
(In reply to rpruen from comment #8) > I noticed that both the rust and rust-bin are installed. Should that happen? Yes, this is not a problem. The Chromium ebuild contains logic to make sure that we select an LLVM slot that matches an installed slot for virtual/rust. I guess we could put in some more effort work out which Rust that is to ensure that it matches the LLVM we selected; I feel like this is way into 'things an eclass should be handling' territory though. It does feel like the Rust and Clang are out of sync. What I've seen so far doesn't seem to support that though - Clang 19 and Rust 1.82.0 are appropriate.
I'll try to look into this over the next week or so; this was a big fortnight for Chromium work unfortunately.
(In reply to rpruen from comment #5) > Created attachment 907314 [details] > build log > > Build log (.zip compressed) > > Same use flag changed between the initial report This attachment is, unfortunately, not a build log. I'm interested in seeing how you do with either the 130 stable or 131 beta that don't have the 'system-toolchain' USE due to upstream issues.
Created attachment 907502 [details] build log Build log Last attempt failed due to the following: mainpc /var/tmp/portage/www-client/chromium-130.0.6723.58/temp # gzip build.log gzip: build.log: Too many levels of symbolic links Sorry about that
(In reply to Matt Jolly from comment #12) > (In reply to rpruen from comment #5) > > Created attachment 907314 [details] > > build log > > > > Build log (.zip compressed) > > > > Same use flag changed between the initial report > > This attachment is, unfortunately, not a build log. > > I'm interested in seeing how you do with either the 130 stable or 131 beta > that don't have the 'system-toolchain' USE due to upstream issues. Trying 131 beta, but this doesn't look quite right: [ebuild U *] www-client/chromium-131.0.6753.0 [129.0.6668.29] WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict: virtual/rust:0 (virtual/rust-1.82.0:0/llvm-19::gentoo, ebuild scheduled for merge) USE="profiler -rustfmt" ABI_X86="(64) -32 (-x32)" conflicts with =virtual/rust-1.81.0-r1 required by (media-sound/helvum-0.5.1-r3-1:0/0::gentoo, installed) USE="-debug" ABI_X86="(64)" LLVM_SLOT="18 -16 -17" ^ ^^^^^^^^^ virtual/rust:0/llvm-18 required by (dev-lang/spidermonkey-115.16.0-1:115/115::gentoo, installed) USE="clang jit lto -debug -test" ABI_X86="(64)" ^^^^^^^^^^ virtual/rust:0/llvm-18[profiler(-)] required by (www-client/chromium-131.0.6753.0:0/dev::gentoo, ebuild scheduled for merge) USE="X cups hangouts kerberos official proprietary-codecs pulseaudio qt5 qt6 screencast system-harfbuzz system-icu system-png system-toolchain system-zstd vaapi wayland widevine -bindist -custom-cflags -debug -ffmpeg-chromium -gtk4 (-headless) -pax-kernel (-pgo) (-selinux)" ABI_X86="(64)" L10N="af am ar bg bn ca cs da de el en-GB es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk ur vi zh-CN zh-TW" ^^^^^^^^^^ =virtual/rust-1.81.0-r1 required by (dev-lang/spidermonkey-115.16.0-1:115/115::gentoo, installed) USE="clang jit lto -debug -test" ABI_X86="(64)" ^ ^^^^^^^^^ virtual/rust:0/llvm-18 required by (media-sound/helvum-0.5.1-r3-1:0/0::gentoo, installed) USE="-debug" ABI_X86="(64)" LLVM_SLOT="18 -16 -17" ^^^^^^^^^^ =virtual/rust-1.81.0-r1[profiler(-)] required by (www-client/chromium-131.0.6753.0:0/dev::gentoo, ebuild scheduled for merge) USE="X cups hangouts kerberos official proprietary-codecs pulseaudio qt5 qt6 screencast system-harfbuzz system-icu system-png system-toolchain system-zstd vaapi wayland widevine -bindist -custom-cflags -debug -ffmpeg-chromium -gtk4 (-headless) -pax-kernel (-pgo) (-selinux)" ABI_X86="(64)" L10N="af am ar bg bn ca cs da de el en-GB es es-419 et fa fi fil fr gu he hi hr hu id it ja kn ko lt lv ml mr ms nb nl pl pt-BR pt-PT ro ru sk sl sr sv sw ta te th tr uk ur vi zh-CN zh-TW" ^ ^^^^^^^^^
OK here's the issue: * Using LLVM/Clang slot 18 to build * Using Rust 1.82.0 to build So we do need to come up with a stronger error. In your case you should be able to select llvm 18 and rust 1.81.x to get you going in the short term, or use llvm19 and rust 1.82.0. I'll work out some logic to flag this early in the build.
(In reply to Matt Jolly from comment #15) > OK here's the issue: > > * Using LLVM/Clang slot 18 to build > * Using Rust 1.82.0 to build > > So we do need to come up with a stronger error. > > In your case you should be able to select llvm 18 and rust 1.81.x to get you > going in the short term, or use llvm19 and rust 1.82.0. > > I'll work out some logic to flag this early in the build. Thanks for the tip. I will try it. From the virtual/rust:0 message below (virtual/rust-1.82.0:0/llvm-19) LLVM_SLOT="18 -16 -17" shouldn't that be slot 19? Or am I missing something?
Yes, that should only support llvm 19 for rust 1.82. I have a solution for Chromium / Rush that looks good, hopefully we can get it merged pretty soon.
(In reply to Matt Jolly from comment #17) > Yes, that should only support llvm 19 for rust 1.82. > > I have a solution for Chromium / Rush that looks good, hopefully we can get > it merged pretty soon. Great thanks you!
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=542e055db9a8c762714d3870816f8a5c6e52f853 commit 542e055db9a8c762714d3870816f8a5c6e52f853 Author: Matt Jolly <kangie@gentoo.org> AuthorDate: 2024-11-03 00:15:32 +0000 Commit: Matt Jolly <kangie@gentoo.org> CommitDate: 2024-11-09 05:31:28 +0000 rust.eclass: Introduce new eclass for slotted Rust The rust eclass acts similarly to the llvm eclass. It works with optional `RUST_{MAX,MIN}_SLOT` variables to enable ebuilds to trivially dependencies on appropriate Rust SLOTs. A `RUST_NEEDS_LLVM` variable can be set to have the eclass read `LLVM_COMPAT` and generate an llvm-r1-USE-gated dependency string. `RUST_USEDEP`, if set will be included in the dependency string and checks against installed packages. In either case these are stored in `RUST_DEPEND` for consumpion in the ebuild, and added to BDEPEND unless unless `RUST_OPTIONAL` is set. `RUST_DEPEND` will only ever include in-tree slots; there is no need to set `RUST_MIN_VER` if all in-tree versions are suitable. If `RUST_MIN_VER` is set to a value older than the oldest in-tree slot it is treated as if it is set to the lowest available. The default `rust_pkg_setup` will prefix the selected slot to `PATH` and export `RUSTC` and `CARGO` variables pointing to that slot for ease-of-use. This should prevent issues like: Bug: https://bugs.gentoo.org/907492 Bug: https://bugs.gentoo.org/942444 Signed-off-by: Matt Jolly <kangie@gentoo.org> eclass/rust.eclass | 464 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 464 insertions(+)
Hi, The new slotted rust should resolve the issue permanently. Please let me know how you go!
(In reply to Matt Jolly from comment #20) > Hi, > > The new slotted rust should resolve the issue permanently. Please let me > know how you go! Thank you. I have started updating @world and will report back. It will be a few days because chromium is a long compile.
Based on what we've seen since bringing in the Rust eclass I'm going to call this one resolved. Please let me know if you have any further issues with this.
Sorry for the delay. I can report that this has solved the problem. Thank you.
