ERROR: dev-lang/rust-1.71.1::gentoo failed SOLVED

[mich]

Hello,
I ran twice but always failed.
Here the log emerge info: https://transfer.sh/RVXBPEm8so/emerge-info
Build log: https://transfer.sh/zU8aG7wrnl/build.log

Can somebody help me please?
Michel

[fedeliallalinea]

[mich]

[mich]

[fedeliallalinea]

Can you post dmesg with wgetpaste (If you have rebooted the system after the error, nothing will be seen)?
It would have been enough to give emerge -1 dev-lang/rust-bin command.
_________________
Questions are guaranteed in life; Answers aren't.

[Ionen]

I wonder what kind of error it gives if rather than "run out" of memory+swap, it tried to use over 4GB on x86 for a single process, and if it may be what happened here.

fwiw do try with USE=-lto (there's been some talk that maybe should just mask it on x86 for rust), albeit personally I'd just use rust-bin on x86-32 machines rather than build it either way (aka emerge -1 rust-bin && emerge -c dev-lang/rust)

[mich]

[mich]

[Ionen]

May want to try with -v to see what is still preventing depclean, aka emerge -pvc dev-lang/rust.

But I assume it's because of mismatching USE, check in /etc/portage for anything you set on dev-lang/rust (if any) and set it on dev-lang/rust-bin too (or maybe cleanup flags on virtual/rust if any and re-emerge that).

Alternatively could potentially be a bad package that depends directly on dev-lang/rust when it should be depending on virtual/rust, the -pvc command would show it (if all it shows is virtual/rust then it's probably flags, if it shows other packages then it could be that).

[mich]

[Ionen]

Oh right, guess it's just because the virtual is outdated

emerge -1 virtual/rust too

[mich]

[mich]

[Ionen]

Do you not have up-to-date rust-bin still installed right now? the virtual would be happy with either rust or rust-bin, but you need to have a version that matches it installed.

Edit: aka emerge -1 rust-bin virtual/rust should do it in theory unless there's still something else going on, then try to depclean dev-lang/rust again

[mich]

[mich]

[mich]

[Pasketti]

I was having the same problem, but it was a memory issue for me.

I'm running on a minimal Linode VM with 1G of RAM, and 2G of swap.

This is normally enough for anything I do. My needs are simple.

I created a temporary 1G swap file and tried again. Failed.

2G swap file. Failed.

It wasn't until I created a 4G swap file (for a total of 6G swap) that it finally finished.

[MerlinYoda]

I have a somewhat older test server that I've run Gentoo on for quite a while without issue but it seems like this package still won't compile regardless of how much swap space I throw at it. I was up to 7GB of total swap space with 2 GB of system memory and I am still getting the same sort of errors as the OP. However, I just realized after this latest failure that the system is actually still running on a 32-bit kernel even though it's running on a 64-bit processor. This got me wondering as to whether anyone would actually be able to compile this package under a 32-bit OS if the memory requirements to successfully compile are so high. I mean, has anyone actually checked if it's possible on such a system prior to marking the package as "stable" for the x86 branch? If it isn't a part of the stabilization process already, adding compilation checks using a fresh stage3 system for a given branch (x86, amd64, arm64, etc.) for any given package would be nice.

I'm going to go ahead and use the binary package instead to compensate for being unable to compile from source but it's a shame that the upstream developers couldn't have designed a language whose compiler wasn't so resource-intensive to build.

[sublogic]