Do you rember what command it was running when it hanged? Issue.
@brson what am I doing wrong?
max@pc MSYS ~ $ rustup show nightly-i686-pc-windows-gnu (default toolchain) max@pc MSYS ~ $ rustup toolchain list nightly-i686-pc-windows-gnu (default) max@pc MSYS ~ $ rustup default x86_64-pc-windows-gnu error: toolchain 'x86_64-pc-windows-gnu' is not installed max@pc MSYS ~ $ rustup override add x86_64-pc-windows-gnu error: toolchain 'x86_64-pc-windows-gnu' is not installed
I can reproduce the issue. I can run
rustup commands using the msys shell but I see 2
rustup.exe processes in the Task Manager which cannot be killed.
cargo update hangs (not sure if it’s related or maybe it’s because I am using 32 bit binaries?)
I get this error when trying to install rustup on AArch64:
info: syncing channel updates for 'stable-aarch64-unknown-linux-gnu' error: some components unavailable for download: 'rustc', 'rust-docs', 'cargo' rustup: command failed: /tmp/tmp.6O56q7aU5O/rustup-init
It seems that aarch64 rustc is only available on nightly. I worked around it by installing the nightly toolchain manually, however it would be nice if this was done automatically at installation time (when first running the script from curl), If a stable toolchain for the current architecture is not available then it should automatically fall back to a beta or nightly toolchain.
override commands need to be passed the toolchain name
stable-x86_64-pc-windows-gnu. Note the ‘stable’.
Thanks for the details about the hanging issue. I’ve tried just doing some normal rustup commands and looking for zombie instances in task manager, but so far haven’t reproduced what you are seeing.
It certainly sounds related. This isn’t a bug that I’ve heard of. Does
cargo update hang consistently or just sometimes?
@Amanieu Thanks for the report about aarch64. I agree this error needs to be a lot better. So many people have hit it testing out the new platforms.
Any cargo command hangs, even
cargo without any extra argument. In Process Explorer I can see
multirust.exe seem to actually call
cargo so I think it’s actually
multirust.exe that has an issue. No idea how
multirust.exe is involved in the whole chain.
I did some more tests and I am pretty sure it has something to do with the 32 bit binaries as all the issues disappear if I manually download and use 64 bit
rustup-init.exe to install the toolchain.
I was too quick to say that everything works when using the 64 bit binaries only.
cargo build still hangs (actually
rustc seem to hang).
cargo update works fine.
Last strace lines for
cargo build :
--- Process 9208 loaded C:\Windows\System32\shell32.dll at 000007FEFE450000 --- Process 9208 loaded C:\Windows\System32\shlwapi.dll at 000007FEFD8E0000 --- Process 9208 loaded C:\Windows\System32\userenv.dll at 000007FEFD180000 --- Process 9208 loaded C:\Windows\System32\profapi.dll at 000007FEFD040000 --- Process 9208 loaded C:\Windows\System32\ws2_32.dll at 000007FEFDD20000 --- Process 9208 loaded C:\Windows\System32\nsi.dll at 000007FEFE010000 --- Process 9208 loaded C:\Windows\System32\dbghelp.dll at 000007FEF836 --- Process 9208 loaded C:\Windows\System32\shell32.dll at 000007FEFE450000 --- Process 9208 loaded C:\Windows\System32\shlwapi.dll at 000007FEFD8E0000 --- Process 9208 loaded C:\Windows\System32\userenv.dll at 000007FEFD180000 --- Process 9208 loaded C:\Windows\System32\profapi.dll at 000007FEFD040000 --- Process 9208 loaded C:\Windows\System32\ws2_32.dll at 000007FEFDD20000 --- Process 9208 loaded C:\Windows\System32\nsi.dll at 000007FEFE010000 --- Process 9208 loaded C:\Windows\System32\dbghelp.dll at 000007FEF836
I see that
rustc gets immediately suspended (visible in System Monitor -> Analyze Wait Chain). There are no more details on why it is suspended. I guess the antivirus (Symantec) has something to do with it even if I cannot find any info in the logs.
I don’t have these issues if I manually download and install Rust. I guess it has something to do with how rustup is downloading the binaries.
Could it be that Symantec does not like binaries that suddenly pop up on the file system without being connected to an installation process?
Yikes. I hope if that’s the case that it is solvable. Perhaps you can try one more kind of test. Instead of calling just
cargo can you call
C:\Users\$YOURNAME\AppData\Local\.cargo\toolchains\stable\bin\cargo (or something like that) and confirm that that behaves correctly?
I guess you mean to run
I tried it and it worked every time!
Then I realized the binaries under
~/.cargo/bin are some sort of wrappers or something which are actually calling the ones in
~/.multirust/toolchains/<toolchain>/bin. Maybe this indirection is causing all the problems.
Edit: fix typos
rustup 0.1.9 is out. This release includes a critical security fix, so please upgrade.
In this case rustup wasn’t doing TLS hostname verification, which is absolutely required for TLS to be secure. Hyper uses OpenSSL for TLS by default but at this point doesn’t implement hostname verification.
To solve this I used @sfackler’s new rust-native-tls crate. This provides TLS backed by the most appropriate implementation for each platform, including Windows’ schannel and OS X’s security framework. Most importantly it includes a hostname verifier for OpenSSL. Here’s where it’s wired up to Hyper.
For those using Hyper this is probably the right way to set up TLS at the moment. It’s so important to this get right I expect it will get easier to do quickly.
rustup self update <-- this is the best feature! It’s so easy
Thanks for all the hard work!
Getting back to my rustup install problems a bit later. The latest installer gives more of a hint by saying
error: toolchain ‘stable’ is not installed info: caused by: not a directory: ‘/Users/chrish/.multirust/toolchains/stable-x86_64-apple-darwin’
I renamed away ~/.multirust, and now the install succeeds. I’ve kept the old directory, so if you want me to run tests, let me know. At least I feel that if rustup doesn’t like old multirust installs, it’d be nice if it detected them and complained in a even more specific way. But otherwise, things seem to work fine so far for me, now.
Yeah, I’m sorry about that. I put some defensive code in the installer this time to catch the most common cases where old rust tools are in the way. It would still not catch this though. Issue. This will also stop being a problem when the directory is finally renamed to
Thank you for the code offer but I don’t need it at this time.
But then people will have an obsolete
~/.multirust directory and it wouldn’t be obvious that it doesn’t serve any purpose anymore. Actually I would expect multirust to delete that directory when I uninstall, but I guess it makes no sense to add this “functionality” now since a lot of users have already started migrating to rustup.rs.
Once the directory changes to
~/.rustup it would be nice to at least have an option during install to delete the obsolete files from former multirust.
It’s due to technical limitations in rust-installer that multirust doesn’t clean up its metadata.
C:\msys64\home\Peter> rustup update x86_64-gnu-nightly error: toolchain 'x86_64-gnu-nightly' is not installed C:\msys64\home\Peter> rustup update nightly-x86_64-gnu info: syncing channel updates for 'nightly-x86_64-pc-windows-gnu'
The first target triple is the kind I’d use with multirust-rs, so to change the triple ordering and then give me such an unhelpful error message isn’t very nice.
Furthermore, while I can choose where to install rustup during the installation procedure, it then goes ahead and installs the toolchains wherever it feels like, not giving me any control over that.
In the readme it has two commands listed
rustup toolchain install nightly and
rustup install nightly, neither of which work.
I can’t figure out how to add targets.
C:\msys64\home\Peter> rustup target add nightly-i686-gnu error: toolchain 'x86_64-msvc-nightly' is not installed info: caused by: not a directory: 'C:\Users\Peter\.multirust\toolchains\x86_64-msvc-nightly' C:\msys64\home\Peter> rustup target add i686-pc-windows-gnu error: toolchain 'x86_64-msvc-nightly' is not installed info: caused by: not a directory: 'C:\Users\Peter\.multirust\toolchains\x86_64-msvc-nightly' C:\msys64\home\Peter> rustup target add nightly-i686-gnu --toolchain nightly-x86_64-gnu error: toolchain 'nightly-x86_64-pc-windows-gnu' does not contain component 'rust-std' for target 'nightly-i686-gnu' C:\msys64\home\Peter> rustup target add nightly-i686-pc-windows-gnu --toolchain nightly-x86_64-pc-windows-gnu error: toolchain 'nightly-x86_64-pc-windows-gnu' does not contain component 'rust-std' for target 'nightly-i686-pc-windows-gnu'
What control are you expecting? And what do you mean that you can choose where to install rustup? There aren’t any options to configure the installation location.
These commands were just added in 0.1.10 which was just published minutes ago. I’ve filed a PR to make the README more consistent.
Your second command is the right one, but it looks like it’s being affected by the bug in your first report where the toolchain naming scheme changed. Probably if you run
rustup default nightly it will fix the name of the default toolchain and make this work again. If it continues to be broken I’d just delete
Thanks for the report.
rustup 0.1.10 is out.
This contains fixes for the most egregious problems with the new TLS stack on Windows, particularly the long hangs during download. I’m going to try to get another build out later today that converts from hyper to curl to solve the Windows TLS problem better.
Oh, I used the
CARGO_HOME environment variable to tell Rustup where to install itself.