RalfJung
commented
1 year ago We don't support .json files for targets, so I suspect that is the underlying cause here. The error looks strange though and I cannot make any sense of it...
Open ProfElements opened 1 year ago
RalfJung
commented
1 year ago We don't support .json files for targets, so I suspect that is the underlying cause here. The error looks strange though and I cannot make any sense of it...
RalfJung
commented
1 year ago So, closing as a duplicate of https://github.com/rust-lang/miri/issues/2053. Thanks for the report!
ProfElements
commented
1 year ago It does the same thing for my default system Target: px86_64-unknown-linux-gnu
Error:
rosalina ❯ cargo miri setup
Preparing a sysroot for Miri (target: x86_64-unknown-linux-gnu)...
Compiling compiler_builtins v0.1.84
Compiling core v0.0.0 (/home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core)
Compiling libc v0.2.135
Compiling cc v1.0.76
Compiling memchr v2.5.0
Compiling std v0.0.0 (/home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/std)
Compiling unwind v0.0.0 (/home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/unwind)
Compiling rustc-std-workspace-core v1.99.0 (/home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core)
Compiling alloc v0.0.0 (/home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/alloc)
error[E0465]: multiple rmeta candidates for `core` found
--> /home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs:4:9
|
4 | pub use core::*;
| ^^^^
|
note: candidate #1: /tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps/libcore-1ad36d05c04c5479.rmeta
--> /home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs:4:9
|
4 | pub use core::*;
| ^^^^
note: candidate #2: /tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps/libcore-9a9a7836d41bc1e7.rmeta
--> /home/profelements/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs:4:9
|
4 | pub use core::*;
| ^^^^
error: could not compile `rustc-std-workspace-core` due to previous error
fatal error: failed to build sysroot, see error details aboveI do not think the custom target is the issue
RalfJung
commented
1 year ago Oh. Okay that is something else then. Still absolutely no idea why it would build libcore twice though. x86_64-unknown-linux-gnu works fine on my system and on CI and for probably quite a few people out there... this is mysterious. Can you think of anything that is special about your setup? What distro are you using? What's your Miri version (cargo miri -V) and how did you install it? Is there anything in your global cargo config?
(I assume the p in "px86_64-unknown-linux-gnu" is a typo.)
ProfElements
commented
1 year ago Miri: version: miri 0.1.0 (e0098a5 2022-11-29) Os: OS: Pop!_OS 22.04 LTS x86_64
I have nothing in my global cargo config
RalfJung
commented
1 year ago And miri is installed via rustup I assume?
ProfElements
commented
1 year ago It is
RalfJung
commented
1 year ago Hm. Pop!_OS seems to be a Ubuntu derivative so unlikely to do anything odd. (I asked because if it would have been NixOS or something like that that might have been a hint.^^)
Yeah I'm kind of stumped here. Either the single build of core produces two rmeta files (but why would it do that) or somehow the tmpdir that Miri creates is not empty and contains some old junk rmeta files.
Does the /tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps/ folder still exist? Can you show the output of ls -lah /tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps/?
ProfElements
commented
1 year ago rosalina ❯ sudo ls -lah /tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps
ls: cannot access '/tmp/.tmpNPVcjY/target/x86_64-unknown-linux-gnu/release/deps': No such file or directoryAh yeah Miri is probably too efficient at cleaning this up.^^ But it's unlikely that the folder would already exist, tempdir should handle creating a new fresh folder.
Yeah sorry I am stumped here, and I can't really debug what I cannot reproduce. I hope someone else will see this and have an idea (or it happens to someone else so that we can start looking for things your systems have in common).
RalfJung
commented
1 year ago I guess one thing we could do is add support for cargo miri setup -v, just to get a bit more information out of these logs. I'll add implementing that to my todo list.
RalfJung
commented
1 year ago @ProfElements could you try updating to the latest nightly, and do cargo miri setup -v? That should at last give us a bit more logging...
bindsdev
commented
1 year ago @RalfJung as you directed me in the referenced issue, here is the output, at the point when it fails, of cargo miri setup -v --target CUSTOM_TARGET when I run it:
Running `/home/binds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri --crate-name rustc_std_workspace_core --edition=2021 /home/binds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=192 --crate-type lib --emit=dep-info,metadata -C opt-level=3 -C embed-bitcode=no -C metadata=f903b058488e1652 -C extra-filename=-f903b058488e1652 --out-dir /tmp/.tmpqspPUK/target/x86_64-prestige/release/deps --target /home/binds/code/prestige/.cargo/targets/x86_64-prestige.json -L dependency=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps -L dependency=/tmp/.tmpqspPUK/target/release/deps --extern 'noprelude:alloc=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/liballoc-b6b891d16f2b88c2.rlib' --extern 'noprelude:compiler_builtins=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcompiler_builtins-a90cc2465041ffba.rlib' --extern 'noprelude:core=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-fe8fccd3bdf8e7b3.rlib' --extern core=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-5484c1dfc1494680.rmeta -Z unstable-options -Cdebug-assertions=off -Coverflow-checks=on -Zforce-unstable-if-unmarked`
error[E0464]: multiple candidates for `rmeta` dependency `core` found
--> /home/binds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs:4:9
|
4 | pub use core::*;
| ^^^^
|
= note: candidate #1: /tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-5484c1dfc1494680.rmeta
= note: candidate #2: /tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-fe8fccd3bdf8e7b3.rmeta
For more information about this error, try `rustc --explain E0464`.
error: could not compile `rustc-std-workspace-core` due to previous error
Caused by:
process didn't exit successfully: `/home/binds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/bin/cargo-miri --crate-name rustc_std_workspace_core --edition=2021 /home/binds/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/rustc-std-workspace-core/lib.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --diagnostic-width=192 --crate-type lib --emit=dep-info,metadata -C opt-level=3 -C embed-bitcode=no -C metadata=f903b058488e1652 -C extra-filename=-f903b058488e1652 --out-dir /tmp/.tmpqspPUK/target/x86_64-prestige/release/deps --target /home/binds/code/prestige/.cargo/targets/x86_64-prestige.json -L dependency=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps -L dependency=/tmp/.tmpqspPUK/target/release/deps --extern 'noprelude:alloc=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/liballoc-b6b891d16f2b88c2.rlib' --extern 'noprelude:compiler_builtins=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcompiler_builtins-a90cc2465041ffba.rlib' --extern 'noprelude:core=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-fe8fccd3bdf8e7b3.rlib' --extern core=/tmp/.tmpqspPUK/target/x86_64-prestige/release/deps/libcore-5484c1dfc1494680.rmeta -Z unstable-options -Cdebug-assertions=off -Coverflow-checks=on -Zforce-unstable-if-unmarked` (exit status: 1)
fatal error: failed to build sysroot: sysroot build failedI am on Windows 11 using WSL 2.
RalfJung
commented
1 year ago Is that the full output? It doesn't contain the extra infoemation that "-v" would print.
Also I was asking about "cargo miri setup -v" without "--target".
bindsdev
commented
1 year ago Is that the full output? It doesn't contain the extra infoemation that "-v" would print.
Also I was asking about "cargo miri setup -v" without "--target".
I had omitted the rest up until that point because it was extremely long. I can send it later today, and will also run without --target.
RalfJung
commented
1 year ago You can post it in a foldable comment like this
<details>
log
</details>
(the empty lines are important)
bindsdev
commented
1 year ago Here is the full output.
bjorn3
commented
1 year ago It looks like cargo does both a regular build as well as a check build of several crates for some reason. Do you have build-std in .cargo/config.toml or something?
RalfJung
commented
1 year ago There's actually three rustc invocations for libcore in total? Very strange.
For reference, here is what it should look like:
There's only one --crate-name core here.
bindsdev
commented
1 year ago It looks like cargo does both a regular build as well as a check build of several crates for some reason. Do you have build-std in .cargo/config.toml or something?
Yes, here is my config.toml:
[unstable]
build-std = ["core", "compiler_builtins", "alloc"]
build-std-features = ["compiler-builtins-mem"]Ah, that would explain it then. We can't have cargo build std when we are just using cargo to build std our own way...
When build-std is set, I assume we want to skip the Miri sysroot setup entirely and let cargo handle everything?
bindsdev
commented
1 year ago I came across this issue again while looking through the issue list. I would be interested in contributing a fix for this as it would be beneficial for me, and likely others, for Miri to work when build-std is set. I have looked through the source code a bit and I suspect a fix would require changing some code in the cargo-miri/src/phases.rs file. Would this be the right place? Any guidance on where to start would be appreciated.
RalfJung
commented
1 year ago The first step is to determine whether build-std is set or not. That sounds like we'd need to invoke cargo config get, somewhere in phase_cargo_miri, before setup gets called. And then when it is set, we'll need to figure out what to do -- probably skip the Miri sysroot setup, but the rest heavily depends on how exactly -Zbuild-std works inside cargo. So this could end up requiring a bunch of exploration and debugging the complicated flow of control between cargo-miri and cargo.
bindsdev
commented
1 year ago the rest heavily depends on how exactly -Zbuild-std works inside cargo. So this could end up requiring a bunch of exploration and debugging the complicated flow of control between cargo-miri and cargo.
Would the way we build depend on what crates are specified in use with -Z build-std?
RalfJung
commented
1 year ago I hope not. But I don't know, the only way to figure this out is to try to implement this.
Target
Error