Multirust 0.8 with cross-std installation

1

Hi there.

I've published new revisions of multirust and rustup.sh that enable installation of additional standard libraries for cross compilation.

Note that because this feature depends on server-side metadata generated by the Rust release process, it works only for the nightly channel until the next train passes.

multirust adds the multirust list-available-targets [toolchain] and multirust add-target [toolchain] [target]. These work like so:

brian@ip-10-235-20-183:~/dev/multirust⟫ multirust update nightly
multirust: installing toolchain 'nightly'
rustup: gpg available. signatures will be verified
rustup: downloading manifest for 'nightly'
rustup: downloading toolchain for 'nightly'
######################################################################## 100.0%
gpg: Signature made Tue 08 Mar 2016 11:42:25 AM UTC using RSA key ID 7B3B09DC
gpg: Good signature from "Rust Language (Tag and Release Signing Key) <rust-key@rust-lang.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Subkey fingerprint: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC
rustup: installing toolchain for 'nightly'
rustup: extracting installer
install: creating uninstall script at /home/brian/.multirust/toolchains/nightly/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'rust-std-x86_64-unknown-linux-gnu'
install: installing component 'rust-docs'
install: installing component 'cargo'

    Rust is ready to roll.

brian@ip-10-235-20-183:~/dev/multirust⟫ multirust list-available-targets nightly
aarch64-apple-ios
aarch64-unknown-linux-gnu
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
armv7-apple-ios
armv7-unknown-linux-gnueabihf
armv7s-apple-ios
i386-apple-ios
i686-apple-darwin
i686-pc-windows-gnu
i686-pc-windows-msvc
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
powerpc-unknown-linux-gnu
powerpc64-unknown-linux-gnu
powerpc64le-unknown-linux-gnu
x86_64-apple-darwin
x86_64-apple-ios
x86_64-pc-windows-gnu
x86_64-pc-windows-msvc
x86_64-rumprun-netbsd
x86_64-unknown-linux-gnu
x86_64-unknown-linux-musl

brian@ip-10-235-20-183:~/dev/multirust⟫ multirust add-target nightly arm-linux-androideabi
rustup: downloading extra component from https://static.rust-lang.org/dist/2016-03-08/rust-std-nightly-arm-linux-androideabi.tar.gz
######################################################################## 100.0%
gpg: Signature made Tue 08 Mar 2016 11:21:09 AM UTC using RSA key ID 7B3B09DC
gpg: Good signature from "Rust Language (Tag and Release Signing Key) <rust-key@rust-lang.org>"
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 108F 6620 5EAE B0AA A8DD  5E1C 85AB 96E6 FA1B E5FE
     Subkey fingerprint: C134 66B7 E169 A085 1886  3216 5CB4 A934 7B3B 09DC
rustup: installing extra component from /home/brian/.multirust/rustup/dl/b7da00c49f477349dcc5/rust-std-nightly-arm-linux-androideabi.tar.gz
rustup: extracting installer
install: creating uninstall script at /home/brian/.multirust/toolchains/nightly/lib/rustlib/uninstall.sh
install: installing component 'rust-std-arm-linux-androideabi'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error

    std is standing at the ready.

At which point you can build with cargo build --target arm-unknown-androideabi. You will still need whatever native toolchain components (like gcc) are required for cross-compilation.

rustup.sh gets three new arguments: --list-available-targets, --add-target, and --with-target. The first two operate similarly to multirust while --with-target can install both the compiler and std from a single command.

I've barely tested this live, so give it a shot and see if it works for you.

The future of multirust is rustup.rs

This is the last major update I plan to make to multirust the shell script. My focus now is on multirust-rs, which is going to be rebranded as rustup.rs because 'rustup' is more fun to say and type than 'multirust'. rustup.rs will eventually be the official way to install Rust. Note that I don't recommend switching to multirust-rs yet, but it should be ready within weeks or days.

rustup.rs is written in Rust, so is much more robust and easier to maintain, and it works correctly on Windows. Now that we've got the server-side manifest data working we'll be able to add source installation and installation of e.g. debug-compiled std.

rustup.rs is also going to be responsible for installing whatever NDK components are needed for cross-compilation, deployment and testing.

The immediate plans for rustup.rs are here.

44 Likes
2

Incredible work, @brson!

3

Rad! Does/will rustup support a system-installed Rust? It'd be great to just cargo install rustup with whatever Rust is available (a version of stable managed by the OS package manager, most likely), and continue to use it, while rustup manages other versions.

2 Likes
4

@jdub No. rustup like multirust wants to manage the entire rust world. rustup is the tool that acquires cargo, not the other way around.

If one were to use cargo to install rustup, rustup would immediately set up the environment so the original cargo and rustc were inaccessible.

I'll put thought into your scenario. It may be possible to bootstrap the installation that way, but I'm not sure what it would gain over installing rustup directly from the binaries (the main installation method on unix is going to be yet-another curled shell script).

1 Like
5

I've heard from two people now that after the upgrade multirust list-available-toolchains nightly reported "no channel manifest at ...". This can be fixed by multirust remove-toolchain nightly && multirust update nightly.

The issue is that if you already have nightly up to date multirust won't reinstall it with the new metadata. The problem should resolve itself in 24 hours.

2 Likes
6

Hmm. For my purposes, I would like it if rustup.rs/multirust-rs were installable with a package manager, and could coexist with a package manager installed toolchain without clobbering it (or making it inaccessible).

For a little bit of background, the way I generally deploy software is via a custom Debian derived distribution, that uses APT for all packaging and updates. If I were to deploy Rust based software (haven't yet been able to do so at my dayjob, though hope to propose it the next time I'm implementing an independent application that won't depend on a lot of existing code), I'd want to use the Debian Rust/Cargo packages to build everything, so any of our developers could get their build-deps for our software just like you could for anything else on the system.

However, I would, say, want to use nightly for development so I could use clippy, and probably run CI against stable, beta, and nightly, as well as the distro packaged version which we'll build the shipping packages with, to help catch any issues that might come up in future releases.

So ideally, I'd have the ability to have the distro packaged version accessible even when multirust is loaded into my shell, but then be able to use multirust to switch to one of the multirust managed versions for development purposes. This is pretty much what I do with Python development right now; I use the distro packaged version for actually shipping code, but I have a virtualenv with newer Pylint and Mock for checking and testing my code.

Being able to cargo install multirust isn't really what I'd want; I'd think it would be easier to just have it packaged as a dpkg which tends to help with the bootstrapping problem. But not masking my system installed binaries, until I specifically used multirust to switch to another version, and with a way to deactivate as well, would be quite helpful.

3 Likes
7

Thanks for the detailed feedback @lambda. I'll keep this in mind as I'm working on it. It may be reasonable to have a fallback to the system-installed Rust without a lot of changes to its design. Might require reserving a name for the "system" toolchain so you can say "multirust override system", "multirust default system".

As is multirust can work with the system toolchain if you manually set it up like "multirust update --link-local /usr/".

3 Likes
8

The Ruby-based tools that do version switching use "system" for this purpose, so there's precedence for it, at least.

4 Likes
9

@brson, very nice work, thanks!

Does multirust add-target support adding a local cross-compiled std?
My problem is that I cross-compile to arm-unknown-linux-gnueabi but the version of glibc that Rust compiles against is newer than the version of glibc the target I cross-compile for is(I have a sysroot(aka SDK) I cross-compile Rust against).

Also, for me, multirust the script is the only viable option since multirust-rs can't be used behind a proxy(and I bet there are a lot of companies that use proxies).

10

Would it help to call "rustup" "crossrust" instead? That's definitely the purpose: it's a tool for anyone who wants to work across multiple versions and platforms.

"rustup" is not very descriptive.

11

I actually like multirust more than rustup or may be I just got used to it...

6 Likes
12

What provisions, if any, are in place for creating our own targets outside of the official ones?

13

I am testing multirust-rs for some time now and I haven't encountered any issues yet.

14

Greak work, @brson!

I have two questions:

  • Is it possible to remove a target? E.g. musl doesn't work on OS X, so if you install x86_64-unknown-linux-musl by mistake, being able to remove it would be nice.
  • How are targets upgraded? Along with the relevant toolchain? In this case, being able to remove toolchains is even more important to avoid consuming bandwidth to upgrade targets you don't need.
15

@LilianMoraru No. Custom-compilation of std is on my radar generally, but there are a lot of interrelated issues that I don't think we can tackle yet.

In the meantime the multirust update --link-local command will work to create entire custom toolchains that may have other stds. The only problem with this is that you don't get cargo, but I want to add a cargo fallback so you can use nightly cargo with custom toolchains.

If this was fixed you would use multirust-rs? It needs to work behind proxies. I'd love a patch :wink:

This is likely to end up the predominant way to obtain Rust, and to me "crossrust" sounds like a special-purpose tool. Also, "rustup", while it doesn't have any meaning on its own, does have meaning to the existing Rust community. It's actually a noun / verb used by Rustaceans.

@cmr This is related to my previous comment to @LilianMoraru. Making it easy to build custom stds is definitely on the radar - @alexcrichton and I talk about it a lot at least - and we see this as a first step in that direction. We don't have a design yet, but rustup/cargo + rustbuild are part of the story.

It's not possible to do it automatically right now, but that's just because I haven't added the command. I agree it should be added.

In the meantime - and I know this is awful - $HOME/.multirust/toolchains/nightly/lib/rustlib/uninstall.sh --component rust-std-x86_64-unknown-linux-musl might work.

16

Well, that was just a thing thrown in the ring as a first. "rustup" may have meaning to the existing community, but it is absolutely bare of meaning for anyone from the outside. I cannot imagine it being used as a noun/verb outside of the English speaking world, but YMMV.

This naming an actual problem I have in meetups, courses and at places where we go advertising. People miss the tool because they don't know what it all does.

17

I already use Rust exclusively through multirust.
And since you said that you concentrate your effort on multirust-rs, of course I would switch as soon as it works.

18

FWIW, once this becomes a reality, it will be advertised heavily in the book, etc. We have hesitated to do so because of the lack of windows support in the past. I wonder if that helps.

19

I for one very much like the rustup name

Please make sure to post on reddit, when it's possible to switch to more or less working rustup.rs. I'd be happy to beta test it.

20

I'm having this issue with just rustup.sh --list-available-targets. I had a previous nightly installed iirc, and I just now did curl -sSf https://static.rust-lang.org/rustup.sh | sh -s -- --channel=nightly but now unfortunately I can't --list-available-targets~~indent preformatted text by 4 spaces

EDIT:

sorry, reinstalling with: sudo ./rustup.sh --with-target=x86_64-unknown-linux-musl --channel=nightly
worked like a charm :slight_smile: