Making Rust usable on a rootless, out of the box Linux/macOS system (no system linker)

This may be a rather niche issue, but as an undergrad I had quite a few run-ins with systems on which I have no permission to use the package manager. Normally gcc is installed on Linux, though sometimes not (it's not a default package on most distros). On macOS, the build tools are generally not available and I have no permission to run xcode-select --install.

For most software and language ecosystems, if I can't use the package manager, that's it, there's little hope to get it running. But Rust is so close to runnable it's more frustrating when it doesn't: rustup, Cargo and rustc are all standalone executables with no external library dependencies, they are installable and runnable on a brand new install of Ubuntu/Debian/Fedora/macOS as a non-priviliged user except the system linker invoked through cc, for which one has to install with root privilege. You can't even "just" compile a copy of gcc or clang because you have no compiler (not to mention their other dependencies)!

It would be really nice to be able to compile Rust program on a completely clean install of Linux or macOS, as this should be currently possible unlike on Windows. AFAIK unless cross-compiling, pure-Rust programs don't need any header files or dynamic libraries that isn't shipped by default with standard Linux distros or macOS.

zig cc is a workaround, but in my testing it still breaks when supplied with certain flags (I wasn't able to build any dependencies with proc macros on macOS, for example).

I don't know what is needed to reach the above goal, but I imagine this involves shipping a copy of lld through rustup like we currently do on Windows, and make this usable through -Clinker=lld (but not -Clink-arg=-fuse-ld=lld as we don't have cc).


Rustup does provide a copy of lld, as rust-lld. The main problem with attempting to use that as the linker is that it doesn't typically know about system library paths, so you are likely to get "unable to find library" errors. And the result may not run as expected. That's not a path for folks who want a seamless experience; that would take work to change. I think people are looking at that but I don't know the status of it.

There's been discussion over the years of making rustc capable of compiling C, similar to zig; there are people excited about that idea, but please note that there's no consensus on doing that, and there's no guarantee of it happening anytime soon, or at all.

This is true on Windows but I cannot find rust-lld under a default nightly toolchain on Linux and macOS, not even with llvm-tools component installed.

On Linux it appears to be part of the rustc component, installed at <toolchain>/lib/rustlib/x86_64-unknown-linux-gnu/bin/rust-lld.

1 Like

Ahhh that's where it is. Though I think it still somehow attempt to invoke a system build tool

I believe that path isn't added to the PATH by default, so you would have to either add it yourself or use an absolute path.

There is a plan to add a new flag -Clink-self-contained=linker that will add it automatically, which combined with -Clinker-flavor=gcc-lld replaces the current -Zgcc-ld=lld:

Once that's implemented I assume you could try to use it directly without gcc, but would then run into the issues josh mentions that together rustc and lld still don't know everything required to get a working binary.


Note that if Xcode is around, you do not need to install the command line tools (in fact, I explicitly do not do so for our CI machines because we have a variety of Xcode versions available, but CLT is a unique system-wide resource and controlling its version reliably is not possible (AFAIK). Instead, you can get by with export DEVELOPER_DIR=/Applications/


-C linker=rust-lld successfully references that (but then runs into all the issues associated with trying to use it).

Interesting. I wonder what -Clink-self-contained=linker is meant to do then :thinking:, skimming the (closed) PR implementing it (#96884) it looks like it parses it but doesn't actually change any behavior based on it.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.