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: | UNCONFIRMED --- | ||
Severity: | normal | CC: | BonezTheGoon, gentoo+bugs, pacho, sam, schulz.benjamin |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
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. *** |