Beta testing rustup.rs

[brson]

I’ve been using it for almost a week and seems great! I only miss tab completions, that would be awesome thanks Brian!

Hm, after thinking about this further, tab completions are going to be tricky. rustup does not require root to install but completions are usually installed to /etc. I really don’t want to require admin just for that. I wonder if we might further frob the shell startup files (like we already to to modify PATH) to load completions.

Issue.

[petrochenkov]

How often are new versions of rustup released on http://www.rustup.rs?
The Windows installer from https://win.rustup.rs/ still panics.

[brson]

@petrochenkov They are released irregularly. I just released version 0.1.4 within the last hour, and that should have all your fixes on it.

[Bluebird]

“rustup toolchain list” doesn’t indicate the default toolchain.

If I forget which toolchain is the default, the simplest way to find out appears to be “rustc -V” (and to then know that 1.7 is “stable”, etc.) but an asterisk beside the default entry in the output of “rustup toolchain list” would make more sense.

[themax]

I have some issues cross-compiling to linux musl on mac. Any clue what is going on?

$ cargo build --target=x86_64-unknown-linux-musl
...
running: "musl-gcc" "-O0" "-ffunction-sections" "-fdata-sections" "-g" "-m64" "-fPIC" "-static" "-o" "<hidden>/target/x86_64-unknown-linux-musl/debug/build/openssl-sys-extras-de64fc46007aa254/out/    src/openssl_shim.o" "-c" "src/openssl_shim.c"


failed to execute command: No such file or directory (os error 2)
Is `musl-gcc` not installed?

[brson]

“rustup toolchain list” doesn’t indicate the default toolchain.

Good point. It could be like rustup target list which uses parens to indicate the status. The list could say (default) next to the default toolchain and (override) or (active) next to an active override.

Issue.

Edit: rustup show will show the current override, which is usually the default.

[brson]

I have some issues cross-compiling to linux musl on mac. Any clue what is going on?

If you have done nothing else to obtain the native toolchain but run rustup target add then musl-gcc will not be installed. You’ll need a musl C toolchain that crosses from Mac to Linux. I haven’t yet heard of anybody doing this.

So far rustup target only adds the Rust components of the cross toolchain. For practical purposes one still needs a cross C compiler from somewhere. For common crosses these are easily obtainable, but Mac->Linux is a fairly uncommon cross.

[Bluebird]

Hi, is it permissible to make a feature request?

What are the chances that there will be comprehensive support for GNU C/C++ compilers by Rustup on Windows?

The use case I have in mind is where a Rust project requires a library (libsodium) that must currently be compiled in MSYS2. Getting either MSYS2 to be aware of anything outside of itself, or redistributable-installed Rust to find a library compiled in the MSYS2 environment, is a non-trivial task. The recommended approach is to compile Rust from inside MSYS2, thereby completely bypassing the Rustup management loveliness.

It would be great to jettison MSYS2 and do everything in Rustup.

[brson]

@Bluebird I’d say it’s definitely in-scope for rustup, depending on the details: rustup is intended (in the future) to take care of as many of the platform-toolchain-integration details as it possibly can.

Your scenario isn’t one I’ve thought about before though. Is all you need for rustup to detect that msys exists on the system and automatically set up the build to use it (i.e. not to actually go install msys and the libsodium sources)? Because that sounds pretty simple, and is similar to detection that will be required for other native toolchain components.

[Bluebird]

@brson Thanks for your reply. To answer your question, I’d rather get rid of msys2 and just use Rustup. That’s because I’m spending days debugging my setup when I should be getting on with learning Rust programming. And knowing that what I’m learning about such a setup will likely be obsolete a year from now with some out-of-the-box solution, but the time spent learning to code will have lasting benefit.

I just want to get libsodium installed in my Rust/GNU environment so I can compile Rust packages that use it, then move on to writing my own Rust software. It seems like an endless maze to which there are few answers.

[matklad]

Just installed rustup on 32bit Win7 in VirtualBox. Everything worked fine!

[llogiq]

Another data point here, installed rustup on Fedora 23 Linux spin over an ancient multirust version. Got a strange warning at first and my toolchain ceased to work until I rustup updated. Since then, everything went smoothly. 10/10, will recommend to others.

[jschievink]

I’ve somehow managed to mess up my local install. rustup is showing a stable-gnu toolchain which I can’t remove. rustup update stable-gnu will instead update/install the stable-x86_64-pc-windows-gnu toolchain.

PS C:\Users\Jonas\Documents\breeze-emu> rustup toolchain list
nightly-i686-pc-windows-gnu
stable-gnu
stable-x86_64-pc-windows-gnu

Additionally, when I Ctrl+C’d rustup when I was running rustup toolchain remove stable-gnu and it was trying to remove stable-x86_64-pc-windows-gnu instead, I managed to mess it even more up, since now the stable-x86_64-pc-windows-gnu toolchain is still showing up in the list, but no commands work, nor does rustup toolchain remove stable-gnu or rustup toolchain remove stable-x86_64-pc-windows-gnu.

I also got really confused when I tried rustup update i686-pc-windows-gnu-nightly (which worked fine with some older version of multirust-rs) and got “error: toolchain ‘i686-pc-windows-gnu-nightly’ is not installed” - Since I wanted to install the toolchain, this error makes no sense. It should rather tell me that the toolchain doesn’t exist and which ones do exist (or how to find a list of toolchains).

[m4b]

@brson:

I’ve also noticed that I tend to write a small shell script to grab the current lib hash, especially when doing custom linking.

It would be great if we had a command like:

rustup show hash

which outputs the hash with no spaces and no newline.

Maybe this is accessible or documented somewhere, like in a rustc invocation but I can’t seem to find it

[m4b]

Sorry, two more things:

1. It seems like it’s currently not possible to automatically answer Y to the script. I’d like to integrate rustup into my build for Travis ASAP, so hopefully the “Continue?” query will disappear or it will correctly work with something like echo "Y\n" | rustup.sh

2. So I noticed the .multirust nightly dir changed from just nightly to nightly-<host target>. I need to provide a path to the nightly musl target in order to do custom linking, so I’m hoping either the internal path structure will stabilize, or better, a subcommand like rustup target <target name> path will become available to automate this process.

Super excited for this to become the official install =)

[japaric]

@m4b for travis you can probably use something like this.

[m4b]

@japaric thanks, I’ll integrate that solution for now!

But hopefully don’t have to bypass the rustup.sh script just to hack past the stdin indirection in the future

[brson]

I’ve somehow managed to mess up my local install. rustup is showing a stable-gnu toolchain which I can’t remove. rustup update stable-gnu will instead update/install the stable-x86_64-pc-windows-gnu toolchain.

This is due to some changes to the internal metadata format. Toolchain names are ‘normalized’ now. It’s safe to delete ~/.multirust/toolchain/stable-gnu.

Additionally, when I Ctrl+C’d rustup when I was running rustup toolchain remove stable-gnu and it was trying to remove stable-x86_64-pc-windows-gnu instead, I managed to mess it even more up, since now the stable-x86_64-pc-windows-gnu toolchain is still showing up in the list, but no commands work, nor does rustup toolchain remove stable-gnu or rustup toolchain remove stable-x86_64-pc-windows-gnu.

I’d be curious to know what errors you see trying to remove a broken toolchain. I’d expect removing broken toolchains to work.

I also got really confused when I tried rustup update i686-pc-windows-gnu-nightly (which worked fine with some older version of multirust-rs

This is again due to changes in the design - now the channel name goes first and the target last like “nightly-i686-pc-windows-gnu-nightly”.

Sorry about all the breakage, but it just hasn’t seemed worth the effort to code up transitional upgrade code yet (one of the reasons I put big warnings on the download page was to give myself an excuse not to maintain that kind of upgrade continuity).

“error: toolchain ‘i686-pc-windows-gnu-nightly’ is not installed” - Since I wanted to install the toolchain, this error makes no sense

Yep. That’s confusing. Issue.

[brson]

I’ve also noticed that I tend to write a small shell script to grab the current lib hash, especially when doing custom linking.

Interesting case. Issue.

It seems like it’s currently not possible to automatically answer Y to the script. I’d like to integrate rustup into my build for Travis ASAP, so hopefully the “Continue?” query will disappear or it will correctly work with something like echo “Y\n” | rustup.sh

It’s not deployed yet but the script will accept -y, --no-modify-path and --default-toolchain= arguments soon.

So I noticed the .multirust nightly dir changed from just nightly to nightly-<host target>. I need to provide a path to the nightly musl target in order to do custom linking, so I’m hoping either the internal path structure will stabilize, or better, a subcommand like rustup target <target name> path will become available to automate this process.

The toolchain path shouldn’t change again, except that the .multirust dir is going to change to .rustup soon. I intend to get the remaining multirust -> rustup renames done this week.

[jschievink]

I’d be curious to know what errors you see trying to remove a broken toolchain. I’d expect removing broken toolchains to work.

This is what I get after cancelling a rustup toolchain remove:

PS C:\Users\Jonas\Documents\breeze-emu> rustup toolchain remove nightly-i686-pc-windows-msvc
info: uninstalling toolchain 'nightly-i686-pc-windows-msvc'
error: could not remove update hash file: 'C:\Users\Jonas\.multirust\update-hashes\nightly-i686-pc-windows-msvc' (Das System kann die angegebene Datei nicht finden. (os error 2))
PS C:\Users\Jonas\Documents\breeze-emu>

EDIT: And a rustup update ... gives:

PS C:\Users\Jonas\Documents\breeze-emu> rustup update nightly-i686-pc-windows-msvc
info: syncing channel updates for 'nightly-i686-pc-windows-msvc'
info: downloading component 'rustc'
36.42 MiB / 36.42 MiB (100.00%) 1004.80 KiB/s ETA: 0s
info: downloading component 'rust-std'
48.12 MiB / 48.12 MiB (100.00%) 1.07 MiB/s ETA: 0s
info: downloading component 'rust-docs'
5.57 MiB / 5.57 MiB (100.00%) 1.55 MiB/s ETA: 0s
info: downloading component 'cargo'
2.40 MiB / 2.40 MiB (100.00%) 1.06 MiB/s ETA: 0s
info: installing component 'rustc'
info: rolling back changes
error: failed to install component: 'rustc-i686-pc-windows-msvc', detected conflict: '"share/doc/rust/LICENSE-APACHE"'