Build Rust for Custom Targets with .json Target Specs (2026)

Rust’s rustc is an incredibly flexible compiler, and it can generate code for a vast array of architectures and operating systems, not just the common ones. This is all managed through "target specifications," which are JSON files that tell rustc everything it needs to know about the target environment, from its instruction set and ABI to its available libraries and features.

Let’s see this in action. Imagine we want to compile a simple "Hello, world!" for a hypothetical embedded system that uses a RISC-V architecture with a specific floating-point unit and no standard library.

First, we need a target specification file. Here’s a snippet of what that might look like for a riscv32imac-unknown-none-elf target:

{
  "target_name": "riscv32imac-unknown-none-elf",
  "architecture": "riscv32",
  "cpu": "generic-rv32imac",
  "features": "+m,+a,+c,+f,+d",
  "os": "none",
  "vendor": "unknown",
  "abi": "ilp32",
  "linker": "riscv32-unknown-elf-ld",
  "linker_args": [],
  "pre_link_args": [],
  "post_link_args": [],
  "panic_strategy": "abort",
  "disable_redzone": true,
  "emit_debug_symbols": true,
  "supported_emit_config": [
    "debug",
    "optimized"
  ],
  "requires_native_tools": false,
  "no_crt": true,
  "allow_undefined_sections": true,
  "position_independent_executable": false,
  "relocation_model": "static",
  "disable_std": true
}

The disable_std: true is crucial here. It tells rustc not to try and link against the standard library, which is exactly what we want for a bare-metal embedded system. no_crt: true also prevents the C runtime startup code from being linked, which is often not present or needed in such environments.

With this riscv32imac-unknown-none-elf.json file saved, we can tell rustc about it. We can put this file in a directory, say ~/.rustup/targets/riscv32imac-unknown-none-elf/, and then use the rustc command like so:

rustc --target riscv32imac-unknown-none-elf your_program.rs

If your_program.rs is:

#![no_std]
#![no_main]

#[panic_handler]
fn panic(_info: core::panic::PanicInfo) -> ! {
    loop {}
}

fn main() {
    // In a real embedded scenario, you'd interact with hardware here.
    // For this example, we'll just loop indefinitely.
    loop {}
}

Running rustc --target riscv32imac-unknown-none-elf your_program.rs will produce an executable suitable for our hypothetical RISC-V target. The key here is that rustc reads the .json file and configures its entire code generation, linking, and optimization pipeline based on its contents.

The power of target specs lies in their exhaustiveness. They define the target’s word size, endianness, floating-point capabilities, instruction set extensions, calling conventions (ABI), and even how panic handling should behave. You can specify custom linker paths and arguments, control debug symbol generation, and dictate whether a position-independent executable is even possible.

For embedded development, the disable_std and no_crt flags are paramount. They allow you to build truly minimal binaries that don’t rely on any host operating system services or a full-blown C library. This is how you achieve tiny firmware footprints.

When you’re building for a new or obscure platform, you’re essentially defining this JSON file. The Rust community has built a massive collection of these for various architectures and operating systems, which rustup can automatically download and install. However, for custom targets, you’re often writing your own from scratch or adapting an existing one.

The features field in the JSON is particularly interesting. It’s not just a list of CPU features like +m (integer multiplication/division) or +f (single-precision floating-point). It can also be used to enable or disable specific compiler-level features or intrinsics that are relevant to the target. For instance, you might see entries like +atomics or +sync if the target hardware supports atomic operations.

Most people don’t realize that the linker field isn’t just a string pointing to an executable; it can also be a command line with arguments. This allows for highly customized linking processes, such as invoking lld with specific flags or even a custom linker script. This flexibility is what makes Rust so adaptable to highly constrained or specialized environments where a standard linker invocation just won’t cut it.

Once you have a working target spec and have compiled your code, the next logical step is often to figure out how to debug it on the actual hardware or in a simulator, which involves setting up a remote debugging connection.