Summary: | No way to pick rust compiler used in build (was: gnome-base/librsvg-2.56.1 failed to compile) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | anna |
Component: | Current packages | Assignee: | Gentoo Rust Project <rust> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | BonezTheGoon, daiajo, eschwartz, gentoo+bugs, kangie, pacho, sam, schulz.benjamin |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=934385 https://bugs.gentoo.org/show_bug.cgi?id=683420 https://github.com/gentoo/gentoo/pull/39218 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | build.log |
Description
anna
2023-05-31 16:04:41 UTC
Created attachment 862975 [details]
build.log
> error[E0463]: can't find crate for `core`
> |
> = note: the `i686-unknown-linux-gnu` target may not be installed
> = help: consider downloading the target with `rustup target add i686-unknown-linux-gnu`
Can you show the output of `emerge dev-lang/rust -vp` (or `emerge dev-lang/rust-bin -vp` if you use the binary version)?
These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 1.50 s. [ebuild R ] dev-lang/rust-1.69.0-r1:stable/1.69::gentoo USE="-clippy -debug -dist -doc (-llvm-libunwind) (-miri) -nightly (-parallel-compiler) -profiler -rust-analyzer -rust-src -rustfmt -system-bootstrap -system-llvm -test -verify-sig -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -AVR -BPF -Hexagon -Lanai -MSP430 -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Disabling all the forced targets may be related. I haven't changed any of the default USE flags for rust global USE: USE="pulseaudio cups udev dbus policykit udisks nvidia kde qt5 qt6 -amdgpu wayland vulkan" package.use folder: anna@eurekapyros /etc/portage/package.use $ cat * | grep rust >=virtual/rust-1.64.0 abi_x86_32 # required by virtual/rust-1.64.0::gentoo >=dev-lang/rust-bin-1.64.0 abi_x86_32 Oh they're not forced on for rust? Huh, okay (In reply to anna from comment #3) > These are the packages that would be merged, in order: > > Calculating dependencies... done! > Dependency resolution took 1.50 s. > > [ebuild R ] dev-lang/rust-1.69.0-r1:stable/1.69::gentoo USE="-clippy > -debug -dist -doc (-llvm-libunwind) (-miri) -nightly (-parallel-compiler) > -profiler -rust-analyzer -rust-src -rustfmt -system-bootstrap -system-llvm > -test -verify-sig -wasm" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse2" > LLVM_TARGETS="(X86) -AArch64 -AMDGPU -ARM -AVR -BPF -Hexagon -Lanai -MSP430 > -Mips -NVPTX -PowerPC -RISCV -Sparc -SystemZ -WebAssembly -XCore" 0 KiB > > Total: 1 package (1 reinstall), Size of downloads: 0 KiB This shows ABI_X86="(64) -32 (-x32)" (In reply to anna from comment #5) > I haven't changed any of the default USE flags for rust > > global USE: > > USE="pulseaudio cups udev dbus policykit udisks nvidia kde qt5 qt6 -amdgpu > wayland vulkan" > > package.use folder: > > anna@eurekapyros /etc/portage/package.use $ cat * | grep rust > >=virtual/rust-1.64.0 abi_x86_32 > # required by virtual/rust-1.64.0::gentoo > >=dev-lang/rust-bin-1.64.0 abi_x86_32 And here you're setting abi_x86_32 on rust-*bin*, not rust. that paste didn't make it entirely clear, my apologies, those are all from zz-autounmask here's the whole segment: >=virtual/rust-1.64.0 abi_x86_32 # required by virtual/rust-1.64.0::gentoo # required by gnome-base/librsvg-2.54.5::gentoo # required by x11-libs/gtk+-2.24.33::gentoo # required by net-dialup/ppp-2.4.9-r8::gentoo[gtk] # required by net-misc/networkmanager-1.40.0::gentoo[ppp] # required by kde-frameworks/networkmanager-qt-5.98.0::gentoo # required by kde-plasma/powerdevil-5.25.5::gentoo[wireless] # required by kde-plasma/plasma-meta-5.25.5::gentoo # required by @selected # required by @world (argument) >=dev-lang/rust-bin-1.64.0 abi_x86_32 # required by media-tv/kodi-19.4-r4::gentoo # required by kodi (argument) so, if these packages are requiring USE flags that put things in an inconsistent state, that seems like it needs to be addressed The problem is, really, Rust needs proper "LLVM-style" (or Python-style) treatment. Rust could even be slotted, and we have the same problems from slotting already, because we have rust-bin and rust, and while ebuilds can depend on rust, they can't ensure the right rust is used. So, right now, we suffer all the pain of slotting (dep issues, needing machinery in ebuild) but without the benefits of being able to use multiple Rust versions. If I understand correctly, the problem is - dev-lang/rust-bin is installed with ABI_X86="64 32' - As a result, virtual/rust[abi_x86_32] is satisfied - But dev-lang/rust is installed with only ABI_X86="64" - We don't have a way (like Python or LLVM does) to choose the appropriate Rust compiler in the ebuild if multiple are available Possible workarounds for this situation are - Enable ABI_X86=32 for dev-lang/rust (and potentially emerge -C dev-lang/rust-bin) - emerge -C dev-lang/rust to ensure that rust-bin[abi_x86_32] is the rust compiler chosen I was able to solve the specific problem with librsvg by adding this to a file in package.use/ dev-lang/rust abi_x86_64 abi_x86_32 I don't think the _64 version does anything. There are issues with some other packages but I'm not sure they're related so I can bring those up in another ticket as necessary. I'm also not sure if this solution will cause other problems yet. (In reply to anna from comment #11) > I was able to solve the specific problem with librsvg by adding this to a > file in package.use/ > > dev-lang/rust abi_x86_64 abi_x86_32 > > I don't think the _64 version does anything. It doesn't, since it's forced on. That's what the parentheses mean in ABI_X86="(64) -32 (-x32)" > There are issues with some > other packages but I'm not sure they're related so I can bring those up in > another ticket as necessary. I'm also not sure if this solution will cause > other problems yet. If anything this will solve other problems. Unless you have some reason to have both dev-lang/rust and dev-lang/rust-bin installed, I'd remove one; and if you do have a reason to have both I'd ensure they have the same USE flags set. Reassigning to rust@. Nothing gnome@ can do here. FWIW there's no need to reinstall the compiler - I'm able to reproduce the failure and subsequently work around it by running `eselect rust set rust-bin-1.69.0`. Maybe rust should follow other eselect users and migrate to app-alternatives/*? The presence of a :stable slot seems to be vestigal (just checked, even the -9999 in layman uses it) and without that there's not much reason to keep the current complexity around. (In reply to Enne Eziarc from comment #14) > FWIW there's no need to reinstall the compiler - I'm able to reproduce the > failure and subsequently work around it by running `eselect rust set > rust-bin-1.69.0`. > > Maybe rust should follow other eselect users and migrate to > app-alternatives/*? The presence of a :stable slot seems to be vestigal > (just checked, even the -9999 in layman uses it) and without that there's > not much reason to keep the current complexity around. It'd be better go in the other direction and properly slot it, given we've already had to deal with conflicts/alignment and it's a bit painful, and that won't scale as Rust usage grows (especially if e.g. the kernel needs older versions, etc). (In reply to anna from comment #11) > I was able to solve the specific problem with librsvg by adding this to a > file in package.use/ > > dev-lang/rust abi_x86_64 abi_x86_32 > > I don't think the _64 version does anything. There are issues with some > other packages but I'm not sure they're related so I can bring those up in > another ticket as necessary. I'm also not sure if this solution will cause > other problems yet. This fixed things for me today. Thanks! *** Bug 922135 has been marked as a duplicate of this bug. *** *** Bug 936541 has been marked as a duplicate of this bug. *** I changed >=gnome-base/librsvg-2.57.3 abi_x86_32 to >=gnome-base/librsvg-2.57.3 abi_x86_64 abi_x86_32 in package.use/zz-autounmask and gnome-base/librsvg-2.57.3 still fails with error[E0463]: can't find crate for `core` rust & firefox now install okay. librsvg still fails with the same error. All of these: # emerge -DavuN world These are the packages that would be merged, in order: Calculating dependencies... done! Dependency resolution took 30.89 s (backtrack: 1/20). [ebuild R ] gnome-base/librsvg-2.57.3:2::gentoo USE="introspection vala -debug -gtk-doc" ABI_X86="32* (64) (-x32)" 0 KiB [ebuild R ] x11-libs/gtk+-3.24.41:3::gentoo USE="X introspection wayland xinerama (-aqua) -broadway -cloudproviders -colord -cups -examples -gtk-doc -sysprof -test -vim-syntax" ABI_X86="32* (64) (-x32)" 0 KiB [ebuild N ] gui-libs/libdecor-0.2.2-r1::gentoo USE="dbus gtk -examples" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild U ] media-libs/libsdl2-2.28.5-r2::gentoo [2.28.5-r1::gentoo] USE="X alsa dbus gles2 haptic joystick opengl pipewire pulseaudio sound threads udev video vulkan wayland (-aqua) (-custom-cflags) -doc -fcitx4 -gles1 -ibus -jack -kms -libsamplerate -nas -oss -sndio -static-libs -test -xscreensaver" ABI_X86="32 (64) (-x32)" CPU_FLAGS_X86="mmx sse sse2 -3dnow" VIDEO_CARDS="(-vc4)" 0 KiB [ebuild r U ] media-libs/opencv-4.9.0-r1:0/4.9.0::gentoo [4.8.1-r2:0/4.8.1::gentoo] USE="contrib contribdnn eigen features2d ffmpeg* jpeg opengl openmp png python qt5 tiff -atlas% (-contribcvv) -contribfreetype (-contribhdf) (-contribovis) (-contribsfm) (-contribxfeatures2d) (-cuda) (-cudnn) -debug -dnnsamples -doc% -examples -gdal (-gflags) (-glog) -gphoto2 -gstreamer -gtk3 -ieee1394 -jasper% -java -jpeg2k -lapack (-mkl) -non-free -opencl -opencvapps -openexr -qt6 -quirc% -tbb (-tesseract) -test% -testprograms -v4l -vaapi (-vtk) -webp -xine" ABI_X86="(64) -32 (-x32)" CPU_FLAGS_X86="sse sse2 -avx -avx2 -avx512f -f16c -fma3 -popcnt -sse3 -sse4_1 -sse4_2 -ssse3" PYTHON_TARGETS="python3_12 -python3_10 -python3_11" VIDEO_CARDS="-intel" 149,130 KiB [ebuild rR ] media-plugins/frei0r-plugins-1.8.0::gentoo USE="facedetect scale0tilt -doc" ABI_X86="(64) -32 (-x32)" 0 KiB Total: 6 packages (2 upgrades, 1 new, 3 reinstalls), Size of downloads: 149,130 KiB The following packages are causing rebuilds: (media-libs/opencv-4.9.0-r1:0/4.9.0::gentoo, ebuild scheduled for merge) causes rebuilds for: (media-plugins/frei0r-plugins-1.8.0:0/0::gentoo, ebuild scheduled for merge) Would you like to merge these packages? [Yes/No] are blocked from update/rebuild. (In reply to Daiajo Tibdixious from comment #19) > I changed > >=gnome-base/librsvg-2.57.3 abi_x86_32 > to > >=gnome-base/librsvg-2.57.3 abi_x86_64 abi_x86_32 > in package.use/zz-autounmask > and gnome-base/librsvg-2.57.3 still fails with > error[E0463]: can't find crate for `core` I did this for rust, rust-bin & virtual/rust with it still failing. I changed the line for librsvg in /etc/portage/package.use/zz-autounmask to
gnome-base/librsvg abi_x86_64
and it now compiles.
Previously it was
>=gnome-base/librsvg-"version" abi_x86_32 abi_x86_64
where "version" is a version number, I forget what it was.
I was finally able to install the big KDE update, which added this line:
>=gnome-base/librsvg-2.57.3 abi_x86_32
to package.use, so librsvg may fail next time it needs to be rebuilt/updated.
In terms of design, from previous discussions on IRC, we formed some consensus around llvm.eclass (not llvm-r1.eclass)-style RUST_MAX_SLOT and maybe RUST_MIN_SLOT: the idea would be that few things actually need RUST_MAX_SLOT besides things (ab)using nightly, but RUST_MIN_SLOT is pretty common. In terms of the why, I feel like it was covered above, but to summarise: * A virtual depending on two co-installable packages isn't sufficient because you can't depend on virtual/rust to actually guarantee anything, like e.g. a multilib-capable rustc, or even a new enough Rust * As Rust becomes more important (and unavoidable), having more flexibility becomes more important too. * Slotting it makes it easier to bootstrap it without using prebuilt binaries (or at least only having to do it once). * It makes it far easier to test for regressions. * The hard part (the eclass machinery) is _already_ needed because of the situation with multilib/min ver (hence this bug), so slotting dev-lang/rust itself just gets us nice benefits. Plus the fact that dev-lang/rust and dev-lang/rust-bin are coinstallable proves that it can't be hard to handle that part. (In reply to Sam James from comment #24) > > In terms of the why, I feel like it was covered above, but to summarise: > [...] * The odd virtual/rust deps and people trying to work around it leads to horrible pathological cases like bug 934385 which would go away. 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(+) Fixed by slotted Rust. |