Relative path use in RUSTC_WRAPPER has broken

[ctz]

Hello,

I have a special usage (coverage data collection) of cargo, wherein I run:

$ RUSTC_WRAPPER=./admin/coverage-rustc cargo rustc --all-features --profile test --lib --verbose

This used to work, but now doesn't:

   Compiling scopeguard v0.3.3
   Compiling rayon-core v1.3.0
   Compiling cc v1.0.3
   Compiling libc v0.2.34
     Running `./admin/coverage-rustc rustc --crate-name scopeguard /home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/scopeguard-0.3.3/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=634188bf111cdf8b -C extra-filename=-634188bf111cdf8b --out-dir /home/jbp/sct.rs/target/debug/deps -L dependency=/home/jbp/sct.rs/target/debug/deps --cap-lints allow`
     Running `./admin/coverage-rustc rustc --crate-name build_script_build /home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.3.0/build.rs --crate-type bin --emit=dep-info,link -C debuginfo=2 -C metadata=2f5165cfb1277d8d -C extra-filename=-2f5165cfb1277d8d --out-dir /home/jbp/sct.rs/target/debug/build/rayon-core-2f5165cfb1277d8d -L dependency=/home/jbp/sct.rs/target/debug/deps --cap-lints allow`
     Running `./admin/coverage-rustc rustc --crate-name cc /home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/cc-1.0.3/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=ad5a6f47afcf01e2 -C extra-filename=-ad5a6f47afcf01e2 --out-dir /home/jbp/sct.rs/target/debug/deps -L dependency=/home/jbp/sct.rs/target/debug/deps --cap-lints allow`
     Running `./admin/coverage-rustc rustc --crate-name libc /home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.34/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="use_std"' -C metadata=a6e82361ba65c2f6 -C extra-filename=-a6e82361ba65c2f6 --out-dir /home/jbp/sct.rs/target/debug/deps -L dependency=/home/jbp/sct.rs/target/debug/deps --cap-lints allow`
error: Could not compile `cc`.

Caused by:
  could not execute process `./admin/coverage-rustc rustc --crate-name cc /home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/cc-1.0.3/src/lib.rs --crate-type lib --emit=dep-info,link -C debuginfo=2 -C metadata=ad5a6f47afcf01e2 -C extra-filename=-ad5a6f47afcf01e2 --out-dir /home/jbp/sct.rs/target/debug/deps -L dependency=/home/jbp/sct.rs/target/debug/deps --cap-lints allow` (never executed)

Caused by:
  No such file or directory (os error 2)
warning: build failed, waiting for other jobs to finish...
error: Could not compile `rayon-core`.

(etc.)

With a little experimentation, it appears that RUSTC_WRAPPER now needs to be an absolute path. Is that an expected change in behaviour or inadvertent?

Relevant strace snippet from one of the failing subprocesses:

[pid 91797] chdir("/home/jbp/.cargo/registry/src/github.com-1ecc6299db9ec823/scopeguard-0.3.3") = 0
[pid 91797] execve("./admin/coverage-rustc", ["./admin/coverage-rustc", "rustc", "--crate-name", "scopeguard", "/home/jbp/.cargo/registry/src/gi"..., "--crate-type", "lib", "--emit=dep-info,link", "-C", "debuginfo=2", "--cfg", "feature=\"default\"", "--cfg", "feature=\"use_std\"", "-C", "metadata=634188bf111cdf8b", "-C", "extra-filename=-634188bf111cdf8b", "--out-dir", "/home/jbp/sct.rs/target/debug/de"..., "-L", "dependency=/home/jbp/sct.rs/targ"..., "--cap-lints", "allow"], [/* 67 vars */]) = -1 ENOENT (No such file or directory)

Version: cargo 0.25.0-nightly (e08f310 2017-12-24)

[alexcrichton]

Thanks for the report! I believe this was caused by #4788 where the cwd of rustc was locked down. That being said I think this is a bug in Cargo, we should probably, like with CARGO_HOME, just turn RUSTC_WRAPPER into an absolute path early on during compilation.

[robert-w-gries]

I see a similar issue if RUST_TARGET_PATH is not set to the path where a custom specification target file is located:

Compilation Error

$ ls *json
i686-rxinu.json  x86_64-rxinu.json

$ xargo build --target x86_64-rxinu
   Compiling volatile v0.1.0
error: Error loading target specification: Could not find specification for target "x86_64-rxinu"
  |
  = help: Use `--print target-list` for a list of built-in targets

error: Could not compile `volatile`.

Success

$ export RUST_TARGET_PATH=`pwd`
$ xargo build --target x86_64-rxinu
   Compiling volatile v0.1.0
   Compiling x86 v0.9.0 (https://github.com/gz/rust-x86#1e2efb6b)
   Compiling spin v0.4.6
   Compiling bit_field v0.7.0
   Compiling bitflags v1.0.1
   Compiling bitflags v0.7.0
   Compiling once v0.3.3
   Compiling rlibc v1.0.0
   Compiling lazy_static v0.2.11
   Compiling linked_list_allocator v0.4.3
   Compiling multiboot2 v0.3.2 (https://github.com/phil-opp/multiboot2-elf64#aeeb2824)
   Compiling raw-cpuid v2.0.2
   Compiling rxinu v0.1.0 (file:///home/rob/rxinu)
    Finished dev [unoptimized + debuginfo] target(s) in 7.64 secs

This error happens even if xargo is not used,

@alexcrichton Let me know if you would prefer a separate issue opened to track this.

[alexcrichton]

@robert-w-gries since rustc is the one interpreting RUST_TARGET_PATH instead of Cargo I'm not sure that's actually a bug for Cargo to fix unfortunately.

[SergioBenitez]

@alexcrichton Judging from your comment in japaric/xargo#186 (comment):

In #4788 the behavior of Cargo was tweaked to alter the cwd of the rustc process to always be at the workspace root (fixes a few bugs in Cargo and locks down the behavior for procedural macros).

I don't see why @japaric's example in japaric/xargo#186 (comment) shouldn't work:

$ cargo new --lib foo

$ cd foo

$ echo '#![no_std]' > src/lib.rs

$ cargo add heapless

$ rustc -Z unstable-options --target x86_64-unknown-linux-gnu --print target-spec-json > foo.json

$ cargo build --target foo
   Compiling untagged-option v0.1.1
error: Error loading target specification: Could not find specification for target "foo"

Shouldn't cargo be setting cwd to the workspace root (here just the crate root, foo) which is exactly where the target file foo.json is? If so, shouldn't rustc find the file and build properly? Or has something changed in rustc so that it no longer looks for target files in the cwd?

[alexcrichton]

@SergioBenitez oh I believe the issue there is that you're compiling crates from crates.io and Cargo is now switching the cwd even for those crates (as their own workspace root is themselves in Cargo's $HOME/.cargo cache

[SergioBenitez]

@alexcrichton Sorry, are you saying there's a bug in cargo/rustc, or are you saying everything is working as intended and this is an intentional breaking change?

[alexcrichton]

Ah yeah so to clarify I believe everything is working correctly in cargo/rustc and this is an intentional change on Cargo's behalf. (breaking in the technical/pedantic sense)

[robert-w-gries]

Since the discussion is diverging from the original issue, let's move the discussion to #4905

[stale]

As there hasn't been any activity here in over 6 months I've marked this as stale and if no further activity happens for 7 days I will close it.

I'm a bot so this may be in error! If this issue should remain open, could someone (the author, a team member, or any interested party) please comment to that effect?

The team would be especially grateful if such a comment included details such as:

• Is this still relevant?
• If so, what is blocking it?
• Is it known what could be done to help move this forward?

Thank you for contributing!

(The cargo team is currently evaluating the use of Stale bot, and using #6035 as the tracking issue to gather feedback.)

If you're reading this comment from the distant future, fear not if this was closed automatically. If you believe it's still an issue please leave a comment and a team member can reopen this issue. Opening a new issue is also acceptable!

[dwijnand]

ranty mumble about having different types for relative and absolute paths...

I touched the code relative to rustc wrapper recently, so I might be able to find a fix for this.

[dwijnand]

@alexcrichton here's one issue with turning RUSTC_WRAPPER early into an absolute path: export RUSTC_WRAPPER=sccache.

Here's one way to solve it maybe, turn it absolute if it contains > 1 path segment. So RUSTC_WRAPPER=sccache resolves from PATH and RUSTC_WRAPPER=./sccache becomes absolute. Do you like that idea and, also, to your knowledge is it plausible in a cross-platform sense to check "if it contains > 1 path segment"?

[alexcrichton]

@dwijnand I think that'd definitely work! That or always using an absolute path would be fine by me

[dwijnand]

So now this has some notes on how to solve it (and I think it's easy), but I currently don't have much bandwidth to finish this.

[dwijnand]

Fixed by #4995. Test case coming in #6638.