Cargo uses "its rustc" rather than the one mandated by the rustup toolchain

[japaric]

There's this text in the README:

Because the rust-lang/rust tree does not include Cargo, when cargo is invoked for a custom toolchain and it is not available, rustup will attempt to use cargo from one of the release channels, preferring 'nightly', then 'beta' or 'stable'.

And rustup does what it says: It uses e.g. stable Cargo if the custom toolchain doesn't include a Cargo but that Cargo uses e.g. stable rustc rather than the rustc in the custom toolchain.

I think this is a regression because I remember this used to "work". As in Cargo used the custom toolchain rustc.

STR

Sorry this is a little convoluted but avoids having to bootstrap a new rustc to show tho bug:

# Install and switch to the nightly toolchain
$ rustup default nightly

# Create a "custom" toolchain which is actually just the nightly toolchain minus Cargo
$ mkdir -p ~/tmp && cd $_

$ cp -r $(rustc --print sysroot)/../nightly-x86_64-unknown-linux-gnu .

$ rm nightly-x86_64-unknown-linux-gnu/bin/cargo

$ rustup toolchain link custom nightly-x86_64-unknown-linux-gnu

# Install and switch to the stable toolchain
$ rustup default stable

# Remove the nightly toolchain
# (to make rustup fall back to stable Cargo rather than to the nightly Cargo)
$ rustup toolchain remove nightly

# Switch to the custom toolchain
$ rustup toolchain default custom

# Finally, show the bug
$ cargo new --bin app && cd $_

$ edit src/main.rs && cat $_
#![feature(no_core)]
fn main() {
    println!("Hello, world!");
}

# custom (nightly) rustc
$ rustc -V
rustc 1.14.0-nightly (cae6ab1c4 2016-11-05)

# stable Cargo
$ cargo -V
cargo 0.13.0-nightly (eca9e15 2016-11-01)

# Cargo uses the STABLE rustc rather than the "custom" rustc!
$ cargo build
   Compiling app v0.1.0 (file:///home/japaric/tmp/app)
error[E0554]: #[feature] may not be used on the stable release channel
 --> src/main.rs:1:1
  |
1 | #![feature(no_core)]
  | ^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

error: Could not compile `app`.

To learn more, run the command again with --verbose.

cc @brson

[brson]

I think this is a result of #707, making the proxies prepend to PATH, the toolchain path and CARGO_HOME, instead of appending CARGO_HOME then the toolchain path, which was trying to fix #475, making rustup work when CARGO_HOME is not set.

The bug is that by prepending the toolchain path in front of CARGO_HOME, subsequent toolchain invocations are calling the (wrong) toolchain directly, instead of going through the rustup wrapper.

The solution here I think is to change the prepend order, CARGO_HOME first, then the toolchain directory.

[michaelwoerister]

As a workaround, one can copy a nightly Cargo executable into the bin folder of the custom toolchain.

[oli-obk]

just a different symptom of the same issue:

error while loading shared libraries: librustc_driver-fbb47b4392bde8ce.so: cannot open shared object file: No such file or directory

leaving this here so others with similar issues can find this issue

[japaric]

@brson Could we get a new rustup release that contains this fix? A few rustc devs have hit this bug while testing their rustc changes. (Some of us use rustup toolchain link to test dev rustcs with Cargo)