Running cargo miri setup fails when build-std is set globally
#2705
Comments
|
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... |
|
So, closing as a duplicate of #2053. Thanks for the report! |
|
It does the same thing for my default system Error: I do not think the custom target is the issue |
|
Oh. Okay that is something else then. Still absolutely no idea why it would build libcore twice though. (I assume the |
RalfJung
changed the title
cargo miri run --target powerpc-nintendo-wii.json yields multiple rmeta canidates for core foundcargo miri setup yields multiple rmeta canidates for core found (on x86_64-unknown-linux-gnu)
|
Miri: version: miri 0.1.0 (e0098a5 2022-11-29) I have nothing in my global cargo config |
|
And miri is installed via rustup I assume? |
|
It is |
|
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 |
|
|
Ah 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). |
|
I guess one thing we could do is add support for |
|
@ProfElements could you try updating to the latest nightly, and do |
|
@RalfJung as you directed me in the referenced issue, here is the output, at the point when it fails, of 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. |
|
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 |
|
You can post it in a foldable comment like this (the empty lines are important) |
Here is the full output. |
|
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? |
|
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 |
Yes, here is my [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? |
RalfJung
changed the title
cargo miri setup yields multiple rmeta canidates for core found (on x86_64-unknown-linux-gnu)cargo miri setup fails when build-std is set globally
|
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 |
|
The first step is to determine whether build-std is set or not. That sounds like we'd need to invoke |
Would the way we build depend on what crates are specified in use with |
|
I hope not. But I don't know, the only way to figure this out is to try to implement this. |
ghost
mentioned this issue
RalfJung
added
C-bug
|
Would just like to add that this also fails for Arduino Uno (avr) targets. [build]
target = "atmega328p.json"
[unstable]
build-std = ["core"]
[target.'cfg(target_arch = "avr")']
runner = "ravedude uno --baudrate 9600 --open-console"Here's atmega328p.json: {
"arch": "avr",
"atomic-cas": false,
"cpu": "atmega328p",
"data-layout": "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8",
"eh-frame-header": false,
"exe-suffix": ".elf",
"late-link-args": {
"gcc": [
"-lgcc"
]
},
"linker": "avr-gcc",
"llvm-target": "avr-unknown-unknown",
"max-atomic-width": 8,
"no-default-libraries": false,
"pre-link-args": {
"gcc": [
"-mmcu=atmega328p"
]
},
"relocation-model": "static",
"target-c-int-width": "16",
"target-pointer-width": "16"
} |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Target
Error
The text was updated successfully, but these errors were encountered: