Beta testing

Hi, sorry for the late response. I went on vacation! Just determining whether its an interaction between the msi installers and rustup would be a good start.

I agree. Here’s an issue.

1 Like

I am trying to build a dylib with statically linked dependencies on linux with the musl target and rustup, as in the example in Taking Rust everywhere with rustup, but getting strange panics from cargo. Can anyone help?

`$ rustup target add x86_64-unknown-linux-musl

info: component ‘rust-std’ for target ‘x86_64-unknown-linux-musl’ is up to date

$ cargo build --target=x86_64-unknown-linux-musl

thread ‘’ panicked at ‘assertion failed: !ret.is_empty()’, src/cargo/ops/cargo_rustc/ note: Run with RUST_BACKTRACE=1 for a backtrace.`

Edit Btw, I have file and am using the gcc crate to compile some C into the lib.

@william The musl target doesn’t support dynamic linking, so can’t produce dylibs. The assertion you are seeing is probably because of that.

I don’t see that exact assertion in cargo master, so hopefully it’s been fixed to produce a better error.

Just a quick update on what’s going on with rustup. Since the blog post was published over a month ago I took a vacation and have been focused on other things. I know there are some glaring bugs right now (like rustup uninstall not working - use rustup remove instead).

There’s been a steady stream of patches, but I haven’t published a new build yet. Now that rustup is ‘in production’ I’m quite scared of breaking upgrades, and the next upgrade is going to have some big metadata changes. The test suite does not have enough coverage to give me confidence in upgrades (e.g. just before the blog post I completely broke networking on Windows for a week), so I’m trying to hold off on new releases until rustup has a robust set of live upgrade tests. I’ll keep you updated and try to get the upgrades moving again soon.


rustup 0.2 is out. This one has lots of fixes from a number of people. Thanks everyone.


Contributors: Alex Crichton, benaryorg, Benedikt Reinartz, Boutin, Michael, Brian Anderson, Diggory Blake, Erick Tryzelaar, Ivan Nejgebauer, Jeremiah Peschka, Josh Stone, Knight, mdinger, Ryan Kung, Tad Hardesty


There’s a new feature in 0.2 intended to improve the windows experience. The new default-host setting controls which platform rustup installs compilers for. So on Windows, where rustup installs the i686-pc-windows-gnu compiler by default, you can change the default host to e.g. x86_64-pc-windows-msvc and rustup will assume that you want the compiler for that platform unless explicitly told otherwise. This setting can be changed interactively during install or with rustup set default-host.

This feature doesn’t have docs published yet but here’s what I just wrote for the README.

To update rustup, rustup self update.


I was trying to add a homebrew recipe for rustup. So it would be great if the installation supports an option to avoid interactivity (automatically press 1) and a --prefix option to place the installation elsewhere. If I have some time I can try to implement something like that but no promises since I haven’t done any Rust yet so I will take more time than it should.

I don’t know your exact requirements but rustup-init accepts a -y flag that makes installation non-interactive.

You also need to be concerned with rustup self-updates. Presumably if you are installing through homebrew you want homebrew to do the updates, not rustup. For this I’d like to be able to build rustup with a compile-time option to disable self-updates.

I’d like to know more about what you want out of the --prefix option. Part of rustup’s design is to install bins to ~/.cargo, making all Rust bins live in the Cargo world. What would be the effect of --prefix? Putting rustup in a different directory? Putting rustup and the command proxies (rustc, cargo, etc) in a different directory?

The idea with --prefix would be to follow homebrew directory structure and install stuff in /usr/local/Cellar/rustup/0.2.0/

rustup 0.3 is out. Notable this release is a new fix for installing pre-1.8 releases, the beginnings of support for rustls, a mostly-Rust TLS library, a new hack to make the annoying checksum failures sound less dire.


Contributors: Alex Crichton, Brian Anderson, Drew Fisher, geemili, Ivan Petkov, James Lucas, jethrogb, Kevin Yap, leonardo.yvens, Michael DeWitt, Nate Mara, Virgile Andreani


What’s the best way to upgrade an existing install?

1 Like

Generally, rustup self update should do the trick @wezm.


rustup 0.4.0 is out. To get it run rustup self update.

This release brings the hyper backend’s proxy support up to parity with the curl backend and documents how to use HTTP proxies. It also adds a compile-time ‘no-self-updates’ feature for use by those distributing rustup through other package managers.


Contributors: Alex Crichton, Brian Anderson, Ivan Nejgebauer, Jimmy Cuadra, Martin Pool, Wesley Moore


Arch package has been updated, including now using the no-self-update feature :slight_smile:


rustup 0.5.0 is out. To get it run rustup self update.

This release features a more convenient syntax for executing tools from an arbitrary toolchain. Instead of e.g. rustup run nightly rustc, you can now run simply rustc +nightly That is, execute the toolchain command directly, and if the first argument begins with + it identifies a toolchain name and uses it. Neat idea from @DanielKeep. Let me know what you think of it.

It also adds the rustup man command, which simply displays a man page for the active toolchain, contributed by @theindigamer; and continued work by @inejge on creating an HTTP backend using the rustls Rust TLS library.

Finally, this contains mitigations against misconfiguring the rustup install by running it under sudo. If it detects that it is about to write root-owned files to a non-root home dir it will complain. This type of systems-integration code can sometimes cause surprises, so I’m interested in wider testing. If you are running a less-used Unix you might try to run the installer again (no need to uninstall first) and see if it does anything unexpected.

Thanks to everybody who contributed, and thanks to everybody for testing, reporting issues and running rustup!


Contributors: Brian Anderson, Cam Swords, Daniel Keep, Diggory Blake, Florian Gilcher, Ivan Nejgebauer, theindigamer


Hey there.

There’s a bug in the interaction between the currently-deployed rustup and the latest nightlies that you may run into. It doesn’t look like I’ll have a fix out tonight, so I’m giving you a heads up.

The symptoms are that rustup show and rustup target list will panic when they try to print information about the nightly toolchain. As far as I know things will otherwise continue to work.

What’s happened is that we’ve updated the distribution manifest format to include packages of the Rust source code, and the current version of rustup handles this incorrectly in some cases. Since the breakage only seems to affect commands that report toolchain status and not the installation/operation of the toolchain, I intend to press forward, fix the bug in rustup and urge everyone to upgrade.

@Diggsey has already landed a fix (thanks so much!), but since it’s late today I’m not sure if I’ll get it deployed tonight. It could be as late as Monday that I get a fix out.

I apologize for the disruption.


rustup 0.6.0 is out. Update with rustup self update.

As mentioned previously, this fixes a serious bug with manifest handling, wherein rustup show and rustup target list panicked on recent nightlies.

This adds a new rustup component subcommand which is a generalized version of the existing rustup target subcommand. This one though allows installation of any ‘component’ package, a component being the unit of installation in rustup. The cool thing this is going to allow you to do is install the Rust source code, via rustup component add rust-src. Unfortunately, due to bugs in the generation of the rust-src package, it doesn’t work quite yet, and if you try today rustup will report a ‘corrupt manifest’ error. Once the upstream fix is merged though nightlies should begin coming with optional source components.

The installed source is in the lib/rustlib/src directory of the sysroot, and the sysroot can be discovered with rustc --print sysroot. The precise layout of this directory is not specified. Tools are expected to find the source of crates they need by walking the directory and reading Cargo.toml files. As an optimization they can use implicit knowledge of the structure of the rustc source tree to find the right Cargo.tomls quickly, but to be resilient they need to fall back to walking the tree.

Thanks @Diggsey for putting all the pieces together to make the rust-src package happen.

The other new feature in this release is the addition of the --path and --nonexistent options to rustup override unset, which allows overrides to be removed for paths that no longer exist.

Finally, @Boddlnagg has been doing amazing work integrating rustup into a Windows MSI installer. It’s not ready to test yet, but has been making quick progress.


Contributors: Alex Crichton, Brian Anderson, Diggory Blake, Ivan Nejgebauer Josh Machol, Julien Blanchard, Patrick Reisert, Ri, Tim Neumann


@alexcrichton already found a bug in rustup component remove. Fortunately it doesn’t matter much since you can’t install rust-src yet anyway. I’ll try to get some fixes in tomorrow before working rust-src packages are deployed.

rustup 0.6.1 is out. Update with rustup self update.

This fixes a segfault during installation on OS X 10.10+, and makes the rustup component remove command work correctly.

Fixed rust-src packages are still not available on nightly. It looks to me like they should be available Thursday, though there is still more testing to do to verify things work.


Contributors: Brian Anderson, Diggory Blake