there are not target specific code generator, rustc is capable to generate binary code for all supported targets. run
$ rustc --print target-list
to see the full list.
again, rust does not work like, say, gcc, where you have target specific cross compilers such as arm-none-eabi-gcc, arm-linux-gcc, etc.
instead, there is only rustc but you use a command line option to specify the target, e.g. --target thumbv6em-none-eabihf
assuming you are on macos with intel CPU, to download package for the rustc component, you should looking for this section:
[pkg.rustc.target.x86_64-apple-darwin]
available = true
url = "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-apple-darwin.tar.gz"
hash = "3887a121fe1185f23df98bf78eae17ee6d5586f00988b61f75db1dfd8aad605f"
xz_url = "https://static.rust-lang.org/dist/2025-06-26/rustc-1.88.0-x86_64-apple-darwin.tar.xz"
xz_hash = "c8f1ea4fc3e507c8e733809bd3ad91a00f5b209d85620be9013bea5f97f31f24"
note, here the triple name of pkg.*.target.x86_64-apple-darwin states what target platform the package itself is built for, or in other words, what platforms you can run the binary.
for the rustc component, which is itself a compiler, this is known as the "host" triple, but for other components like rust-std, which is not a compiler, the concept of "host" doesn't apply.
specifically, this does NOT mean this is a cross compiler for specific target.
so, what do you need for a toolchain that is used as a "cross compiler" then? here's a short break down:
-
rustc: the (cross) compiler
the triple name of the package determines what target it was built for (thus it can run on), a.k.a. your "host" platform.
-
cargo: the and package manager and build tool.
choose the same target triple as rustc, since you need to run it on the "host" platform.
-
rust-std: the pre-built standard library
the triple name of the package determines what target it is built for, a.k.a. the "target" triple
- when this is the same as
rustc, it is linked when you do "native" compilation;
- when this is different from
rustc, it is used when you do "cross" compilation;
-
rust-src: the source code of the standard library
this component is the same for every triple, thus the manifest uses a whildcard.
some lower tier targets don't have the standard library distributed as pre-built packages, i.e. you can find them in rustc --print target-list but NOT in rustup target list, so there's no package for the rust-std component of these targets in the manifest.
in such cases, you need to install rust-src and build the standard library from source code on demand. this means if you have one of such rare targets, you must use a nightly toolchain.
seriously, why all these hassle at all? why not just use rustup to install the required tools on a local machine with internet connection, and then pack the $RUSTUP_HOME directory up and transfer it to the gapped environment using portable storage device?
rustup can install non-"native" toolchain just fine, you just need to enable the --force-non-host flag, but other than that, everything just works.
for example, suppose you are on a linux machine with amd cpu, the native host triple is x86_64-unknown-linux-gnu, you can install a toolchain that would run on apple machines like this:
$ rustup toolchain install --force-non-host aarch64-apple-darwin
if you want use the toolchain for thumbv6m-none-eabi, just add the rust-std component of the target to the toolchain:
# these two commands are equivalent:
$ rustup target add --toolchain stable-aarch64-apple-darwin thumbv6m-none-eabi
$ rustup component add --toolchain stable-aarch64-apple-darwin rust-std-thumbv6m-none-eabi
you can also add other components to the toolchain, such as rust-docs for offline documentations, and rust-analyzer for editor integration, etc.
after the toolchain is set up locally, just tar or zip the $HOME/.rustup directory (or to be more precise, the $RUSTUP_HOME/toolchains/stable-aarch64-apple-darwin directory), and transfer it to the apple machine, and setup the $PATH environment variable, you are good to go.