Document necessary environment variables for use without rustup

[aochagavia]

Tried to run a test with cargo run tests/run-pass/vecs.rs, but it results on several error messages stating that the following libraries cannot be found (note: I have removed the trailing hashes in the names for clarity):

• rustc_driver.dll
• rustc.dll
• rustc_mir.dll
• rustc_borrowck.dll
• (and a lot more)

The same happens when running miri directly.

When looking at miri.rs I found out that it relies on RUSTUP_HOME and RUSTUP_TOOLCHAIN. After adding those environment variables everything worked correctly. I think this should be documented on the readme.

[oli-obk]

@aochagavia: did you install rust via rustup? That should set those env vars automatically.

[aochagavia]

I compiled it manually with cargo debug. Maybe we could document this under a "Contributing" subsection or something like that?

[oli-obk]

We should actually remove those hacks and move to

let sysroot = std::process::Command::new("rustc")
        .arg("--print")
        .arg("sysroot")
        .output()
        .expect("rustc not found")
        .stdout;
let sysroot = std::str::from_utf8(&sysroot).expect("sysroot is not utf8").trim();
let sysroot = &Path::new(&sysroot);

[aochagavia]

This doesn't work for me. Even trying to compile run the program below results in an error because it cannot find std.dll.

extern crate miri;
fn main() { }

[oli-obk]

I played around on windows. Setting those env vars has zero effect for me. Instead the issue is

• Clippy doesn't work with rustup 1.0 on Windows rustup#876
• cargo test incompatible with latest rustup cargo#3394
• Cargo's test suite no longer works correctly rustup#893
• and other related issues around rustup not setting PATH anymore

Are you sure you didn't misdiagnose this in the main post and accidentally set the PATH variable, too?

Even trying to compile the program below results in an error

I can compile this fine, but running also gives me the error about std.dll

[aochagavia]

I can compile this fine, but running also gives me the error about std.dll

Oops... I meant run! It compiles fine.

[aochagavia]

Setting those env vars has zero effect for me.

You are right. I just tested it again and it didn't work.

[canndrew]

I can't figure out the environment variables to run the tests either. I've installed rust master from git, rustc --print sysroot gives me /home/shum/.local. If I export RUST_SYSROOT=/home/shum/.local then cargo test still complains error[E0463]: can't find crate for `std` .

[solson]

I set RUST_SYSROOT to the result of rustc --print sysroot before compiling Miri. I'd like to make this simpler, but I'm confused by the whole sysroot situation and it hasn't been a priority.

[solson]

Maybe we could use a build.rs script to run rustc --print sysroot and save it somewhere the Miri build can include_str!() it from rather than using a build-time environment variable?

[canndrew]

I set RUST_SYSROOT to the result of rustc --print sysroot before compiling Miri.

Yep, that works.

[solson]

@canndrew I was worried that the RUST_SYSROOT issue would be affecting anyone who tried Miri, but I think it still just affects non-rustup users. Based on rust-lang/rust#39578 I gather you're yet another NixOS user who can't use rustup (like me)?

I should probably try the build.rs approach I mentioned since there are at least 4 NixOS users I can think of interested in building Miri now...

[canndrew]

I gather you're yet another NixOS user who can't use rustup (like me)?

Yep :)

Maybe we could use a build.rs script to run rustc --print sysroot and save it somewhere the Miri build can include_str!() it from rather than using a build-time environment variable?

Seems unfortunate to have the path baked-in at compile time but I don't have a better suggestion.

[solson]

I suppose we could run rustc --print sysroot at runtime. The important thing, I think, is that it uses the sysroot of the rustc that miri was built with.

[RalfJung]

Initialization has moved quite a bit, is this still a problem?

[RalfJung]

This issue actually asks two questions:

• How can miri find the necessary libraries it needs at run-time when not running in rustup? This is now taken care of by the ./miri script; a ./miri install will install a Miri that has the rpath set appropriately.
• How does miri find its "default" sysroot if there is no rustup during build? The answer is to set RUST_SYSROOT.

So, also based on the fact that nobody responded to my question from almost a year agi, I am going to close this.