Running `cargo miri setup` fails when `build-std` is set globally

[ProfElements]

Target

{
    "arch": "powerpc",
    "cpu": "750",
    "data-layout": "E-m:e-p:32:32-i64:64-n32",
    "dynamic-linking": false,
    "env": "newlib",
    "exe-suffix": ".elf",
    "executables": true,
    "has-rpath": true,
    "llvm-target": "powerpc-eabi",
    "linker": "powerpc-eabi-gcc",
    "linker-flavor": "gcc",
    "linker-is-gnu": true,
    "os": "revolution",
    "pre-link-args": {
        "gcc": ["-meabi", "-mhard-float"]
    },
    "panic-strategy": "abort",
    "relocation-model": "static",
    "target-endian": "big",
    "target-family": "unix",
    "target-mcount": "_mcount",
    "target-c-int-width": "32",
    "target-pointer-width": "32",
    "vendor": "nintendo"
}

Error

rosalina  ❯ cargo miri setup --target powerpc-nintendo-wii.json
Preparing a sysroot for Miri (target: powerpc-nintendo-wii.json)...
   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/.tmp7hbq08/target/powerpc-nintendo-wii/release/deps/libcore-5ded7a8114947da2.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/.tmp7hbq08/target/powerpc-nintendo-wii/release/deps/libcore-7aa06ab5b4d41ada.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 above

[RalfJung]

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]

So, closing as a duplicate of #2053. Thanks for the report!

[ProfElements]

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 above

I do not think the custom target is the issue

[RalfJung]

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]

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]

And miri is installed via rustup I assume?

[ProfElements]

It is

[RalfJung]

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]

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 directory

[RalfJung]

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).

[RalfJung]

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]

@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...