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.
1 Like
How often are new versions of rustup released on http://www.rustup.rs?
The Windows installer from https://win.rustup.rs/ still panics.
@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.
ā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.
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?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.
Edit: rustup show will show the current override, which is usually the default.
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.
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.
@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.
@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.
Just installed rustup on 32bit Win7 in VirtualBox. Everything worked fine!
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.
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).
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 
Sorry, two more things:
-
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 -
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 likerustup target <target name> pathwill become available to automate this process.
Super excited for this to become the official install =)
@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 
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.
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 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).
Yep. That's confusing. Issue.
Interesting case. Issue.
It's not deployed yet but the script will accept -y, --no-modify-path and --default-toolchain= arguments soon.
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.
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"'