Does Rust on Linux need to be *installed* on the system to be used?

I was trying Rust in Linux in a VirtualBox VM today, and I was expecting Rust to work by just calling cargo from the extracted archive (like it does in Windows), but it doesn't... Even adding rustc to the PATH doesn't work either because it can't find the standard library.
Does this mean Rust has to be actually installed on the system to be used? Why can it just work from an extracted archive?

you can probably get it to work by setting the RUSTFLAGS env var to --sysroot=/path/to/rustc/sysroot. The path should be the parent folder of the rustc executable's folder.

Looks similar to this questions: Can't find create for std

@oli_obk I'm sure with some setup I can make it work in the directory I extracted to, but my point is, why doesn't it work straight out of the box like in Window. Is the Linux installation dogma being followed for no particular reason - just for dogma?

This actually creates other problems, like making it much more complicated to use multiple Rust installations in the same system. I guess only today I fully understood why multirust is so significant in the Rust community. I never quite understood before. However, it seems 80% of the problems multirust is solving are problems of Rust's own making... (requiring a Rust installation to be a singleton in the Linux system)

PS: Is it the same story in OS X?

My understanding is that there is no problems with rustc itself, but with finding the standard library. Basically, stdlib gets linked by magic, and Cargo has no control over it, which causes problems like this and makes cross compilation tricky (which one standard library do you need to use?).

But there is a general idea of treating stdlib as just another dependency from The relevant RFC is

I've just downloaded the rustc, rust-std and cargo archives, extracted them, moved one directory, adjusted PATH and successfully built a "Hello world" app. So no, you aren't required to install things, whatever that means.

I'd expect running cargo from the tarball to not work because it won't know where to find rustc, then running rustc to not work because the dynamic linker won't find std. To solve the first you can set RUSTC (or PATH), and the second LD_LIBRARY_PATH. Untested.

1 Like

[quote="brson, post:7, topic:5722"]
and the second LD_LIBRARY_PATH
[/quote]Apparently it's not needed any more. I thought you'd be the one to thank for that... :wink:

$ readelf -d rustc | grep RUNPATH
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN/../lib:/usr/local/lib/rustlib/x86_64-unknown-linux-gnu/lib]

Ah, right. That should work correctly on Unix.

Believe it or not, that's how it used to work a while ago and how it still works after bootstrapped make install. Now the split std makes it more difficult for new users choosing to use the tarball directly.

The front page downloads could definitely return to the old format for simplicity sake.