Thanks! I filed a bug.
I downloaded https://static.rust-lang.org/rustup/dist/x86_64-pc-windows-msvc/rustup-setup.exe.
Then I ran installed stable-x86_64-pc-windows-msvc and nightly-x86_64-pc-windows-msvc without issue.
Then I installed nightly-i686-pc-windows-msvc and stable-i686-pc-windows-msvc. I found it confusing that it downloaded the i686 rustc again, instead of just adding i686 support to the existing x86-64 rustc.
Then I learned on IRC that I am supposed to do rustup target add stable-i686-pc-windows-msvc
and rustup target add nightly-i686-pc-windows-msvc
instead, to add cross-compilation targets. But, when I did this, it failed:
error: toolchain 'stable-x86_64-pc-windows-msvc' does not contain component 'rust-std' for target 'stable-i686-pc-windows-msvc'
and
error: toolchain 'nightly-x86_64-pc-windows-msvc' does not contain component 'rust-std' for target 'nightly-i686-pc-windows-msvc'
It would be nice to have the cross-compilation to i686-msvc work. My normal workflow is to do the equivalent of cargo test --target=i686-pc-windows-msvc && cargo test --target=x86_64-pc-windows-msvc
using a cross-compilation setup I did manually.
Otherwise, it was pretty convenient. It would be nice to see the rustup installer signed sooner rather than later, though I know this is annoying.
Otherwise, it seemed to work well! Pretty awesome.
Browsing the site from Firefix fails (Issue), from Chromium it printed curl https://sh.rustup.rs -sSf | sh
.
I added -x
to sh
and ran it on my system (x86_64 kernel, mixed, mostly 32-bit userland from Debian mostly jessie) from a separate user.
It has installed itself and worked well.
Additional target works.
Additional toolchains and cargo not tested.
Nitpick: rustup target list
show non-installable on stable targets like mips-unknown-linux-musl
Default installation weights 304M. With additional musl target - 346M.
Shall I also test using rustup.rs atop of existing multirust installation?
I had the same problem. I had multirust installed previously via homebrew. I uninstalled multirust and did an rm -rf ~/.multirust
and after that everything worked as expected.
@briansmith it should work as expected if you instead write rustup target add i686-pc-windows-msvc
(note there's no "nightly" there). The distinction is that nightly-i686-pc-windows-msvc
is a toolchain identifier whereas i686-pc-windows-msvc
is a simple target triple. So what this command is doing is adding the "i686-pc-windows-msvc" target to the "nightly" toolchain for "x86_64-pc-windows-msvc".
Thanks for the report. Interesting point of confusion.
Yeah, I discovered this too after the 1.8 release. Here's an issue.
No, not yet. I already know it's pretty bad, and I'm not sure yet what I want to do to make it better. Installing over multirust is sure to be bad, so perhaps it's best to just detect that situation and refuse to install. Opinions?
Can you describe what happened in more detail after installing over multirust?
Just FYI, I plan to make the rust-docs package optional soon, and not installed by default. That should cut down some of the install size.
Iād really love if someone smarter than me could make a package for rustup.rs for Arch Linuxās AUR. Iād really love to replace my multirust.sh
package
Shouldnāt be that hard: Iām just not sure how rustup operates in a system-wide fashion. Maybe the PKGBUILD for multirust
is a good starting point?
On Adnroid, it suggests the same command line as in Linux: curl https://sh.rustup.rs -sSf | sh
Letās try:
$ adb shell
shell@hwH60:/data $ cd local/tmp
shell@hwH60:/data/local/tmp $ curl https://sh.rustup.rs -sSf | sh -x
/system/bin/sh: curl: not found
Not the good beginning.
Letās force it forward:
shell@hwH60:/data/local/tmp $ ^D
$ curl https://sh.rustup.rs -sSf > rsbootstrap.sh
$ chmod +x rsbootstrap.sh
$ adb push rsbootstrap.sh /data/local/tmp/
620 KB/s (5100 bytes in 0.008s)
mvp@vi-notebook:C!/tmp$ adb shell
shell@hwH60:/ $ cd /data/local/tmp/
shell@hwH60:/data/local/tmp $
shell@hwH60:/data/local/tmp $ /system/bin/sh -x ./rsbootstrap.sh
+ set -u
+ RUSTUP_UPDATE_ROOT=https://static.rust-lang.org/rustup/dist
+ main
+ need_cmd curl
+ command -v curl
+ >/dev/null
+ 2>&1
+ err need 'curl' (command not found)
+ say need 'curl' (command not found)
+ >&2
+ echo rustup: need 'curl' (command not found)
rustup: need 'curl' (command not found)
+ exit 1
I think at least http://rustup.rs site should recognize Android and not offer that line for execution, instead explaining the correct way of getting Rust code running on Android.
Sorry, I was kind of on the go, so I didnāt investigate at all before going with the nuclear option of simply removing ~/.multirust
.
Hereās what happened in as much detail as I have:
- I had multirust installed via homebrew.
- I did a
brew unlink multirust
ahead of the installation, Iām not sure if thatās important. - I ran the script from
rustup.rs
- I got the
error: toolchain 'stable' is not installed
error - I tried various things to fix it, but I just got the same error.
brew uninstall multirust
did not help. - I ran
rm -rf ~/.multirust
and ran the installer again, everything worked without problem
I noticed that the self-update happens after everything has been downloaded. Was that intentional? It seems like there might be some benefits to doing the self-update first (Iām envisioning a scenario where rustup itself needs to be updated before it can download new stuff, but fails to update because it canāt download new stuff)
Shall it be ~/.cache/multirust
instead of just ~/.multirust
(and for .cargo
as well)?
Is Rust against XDG?
Or has XDGās idea about .config
and .cache
failed and everybody is moving back to plain old .myprogram.conf
?
I tried running rustup
from behind a corporate firewall, and immediately hit a problem: apparently it doesnāt respect the $https_proxy
environment variable.
Also, +1 for following XDG conventions as closely as possible on the relevant platforms.
I think the website needs a small āother platformsā button - like rust-lang.org - for installers for other platforms. For example, looking at the website on Linux, I wasnāt sure whether I should send it to a Windows user, since I couldnāt immediately tell if it would work for them.
@jnicklas thansks for the details.
@eminence There's a technical limitation in the way that self-update works that forces the actual replacement of the rustup binary to be the last step of installation. Namely, that on windows you can't delete the running executable, so on windows rustup is forced to use an ugly hack: it runs another copy of itself that copies the new binary into place, exiting as it does so that the running binary can be deleted a split second later (iow the actual self-upgrade happens after rustup has reported a successful update and exited). I could possibly add another update step that lets rustup run some upgrade routine before doing the self-exe-replace, but that's scary because if the exe-replacement fails then your upgrade is in an inconsistent state. So right now self-update is as simple as possible.
Rust does not currently support XDG. Here's a previous thread.
This is a problem in hyper. I'll probably fix it by switching to curl.
Good idea. Issue.
The new build contains an expanded interactive installation. Now during install you can press āaā (for āadvancedā) and go through a serious of questions to customize the install. Right now the default toolchain and whether to adjust the PATH variable are the only options.
Some things that I donāt love about it is that the āaā and ānā letters for choosing āadvancedā installation or to cancel, are kinda unobvious (ānā for ācancelāā¦), and not presented in a beautiful way.
The model of answering questions to change the configuration is kinda cumbersome, but weāre quite constrained on what can be done on the console by windows.
The total amount of text is a bit overwhelming too. It might be nice to apply some more style and layout to draw the eyes to the important information.
Iād love to have other examples to crib off of if anybody knows other interactive CLIās that do this kind of thing well.
Iām also curious what people think of rustup now displaying the full toolchain name, including the target:
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'beta-x86_64-unknown-linux-gnu'
info: syncing channel updates for 'nightly-x86_64-unknown-linux-gnu'
info: downloading component 'rustc'
info: downloading component 'rust-std'
info: downloading component 'rust-docs'
info: downloading component 'cargo'
info: installing component 'rustc'
info: installing component 'rust-std'
info: installing component 'rust-docs'
info: installing component 'cargo'
info: syncing channel updates for '1.8.0-x86_64-unknown-linux-gnu'
info: checking for self-updates
info: rustup is up to date
stable-x86_64-unknown-linux-gnu unchanged - rustc 1.8.0 (db2939409 2016-04-11)
beta-x86_64-unknown-linux-gnu unchanged - rustc 1.9.0-beta.1 (37a2869af 2016-04-12)
nightly-x86_64-unknown-linux-gnu updated - rustc 1.10.0-nightly (a0c325980 2016-04-20)
1.8.0-x86_64-unknown-linux-gnu unchanged - rustc 1.8.0 (db2939409 2016-04-11)
This feels really verbose to me, so Iāve considered eliding the target when it is the same as the default, but at the same time showing the full toolchain name does hint that e.g. ānightlyā is short for something else.
Iām in favor of displaying the full toolchain name. The shortened versions should only ever be what the user types in, not what rustup actually does or prints out.
I tried rustup on windows and I get the 32 bit binaries (nightly-i686-pc-windows-gnu
) even though my PC is 64 bit. Is this a known issus?
Later edit:
I noticed rustup-init.exe is 32 bit also.
Another more severe issue is that rustup.exe process seem to be hanging and it cannot be killed from the Windows Task Manager. Due to this issue, I cannot remove the .cargo and .multirust directories and I have to_force_ reboote the PC to recover (using the power button).