Important (Ebuild) I feel like I saw this problem before and then it went away. I'm not 100% sure. Anyway, I see this happening both on Next and 1.4, but it seems to fail in different places. I can also say that this problem didn't exist last week, as I do have gnome-base/librsvg installed on Next.
Rust version on both 1.4 and Next is: rustc 1.63.0 (4b91a6ea7 2022-08-08)
I am not sure if this has anything to do with the Rust update or even that this happens every time. It may be linked to a particular condition that triggers the build fail.
I say that because it breaks in different places on 1.4 and Next, freshly ego-synced.
This is what I get on Next:
Running `rustc --crate-name build_script_build /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/vendor/serde_derive/build.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C embed-bitcode=no -C debuginfo=2 -C debug-assertions=off --cfg 'feature="default"' -C metadata=eb9a14b5c2e87bc9 -C extra-filename=-eb9a14b5c2e87bc9 --out-dir /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/build/serde_derive-eb9a14b5c2e87bc9 -L dependency=/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps --cap-lints allow` The futex facility returned an unexpected error code. error: could not compile `syn `
And this is what I get on 1.4
Compiling encoding-index-japanese v1.20141219.5 Running `rustc --crate-name encoding_index_japanese /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/vendor/encoding-index-japanese/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C debuginfo=2 -C metadata=b1d8698468410940 -C extra-filename=-b1d8698468410940 --out-dir /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps -L dependency=/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps --extern encoding_index_tests=/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps/libencoding_index_tests-cdf21fab809d3888.rmeta --cap-lints allow` error: could not compile `futures-channel`Caused by: process didn't exit successfully: `rustc --crate-name futures_channel --edition=2018 /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/vendor/futures-channel/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type lib --emit=dep-info,metadata,link -C opt-level=3 -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="alloc"' --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=8302ff232bbb7f55 -C extra-filename=-8302ff232bbb7f55 --out-dir /var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps -L dependency=/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps --extern futures_core=/var/tmp/portage/gnome-base/librsvg-2.48.8/work/librsvg-2.48.8/target/release/deps/libfutures_core-f74c5f72694ad002.rmeta --cap-lints allow` (exit status: 134) warning: build failed, waiting for other jobs to finish... error: could not compile `semver-parser`
I thought it could have something to do with incompatibility with parallel compiling. So I just tried a second time to see if it breaks in a different place. To my surprise, it won't break on a second, third, or forth runs.
It looks like the first try will set some condition outside of the build tree (as it's whiped clean on every new emerge, that will fix the system in a way that it won't fail a second time. If that is happening, then sandbox is failing some how.
