tracel-ai/burn · error

Unable to get TARGET_OS

Error message

Unable to get TARGET_OS

What it means

In burn-tch's `build.rs`, `SystemInfo::new` reads the `CARGO_CFG_TARGET_OS` environment variable, which Cargo always sets for build scripts, and `.expect("Unable to get TARGET_OS")` panics if it is missing. This variable is only defined when the script runs under Cargo's build-script environment; running the build script directly, or via tooling that strips the environment, triggers the panic. It is a build-time (compile-of-dependency) failure, not a runtime error in your application.

Source

Thrown at crates/burn-tch/build.rs:47

#[allow(dead_code)]
#[derive(Debug, Clone)]
struct SystemInfo {
    os: Os,
    cxx11_abi: String,
    libtorch_include_dirs: Vec<PathBuf>,
    libtorch_lib_dir: PathBuf,
}

fn env_var_rerun(name: &str) -> Result<String, env::VarError> {
    println!("cargo:rerun-if-env-changed={name}");
    env::var(name)
}

impl SystemInfo {
    fn new() -> Option<Self> {
        let os = match env::var("CARGO_CFG_TARGET_OS")
            .expect("Unable to get TARGET_OS")
            .as_str()
        {
            "linux" => Os::Linux,
            "windows" => Os::Windows,
            "macos" => Os::Macos,
            os => panic!("unsupported TARGET_OS '{os}'"),
        };
        // Locate the currently active Python binary, similar to:
        // https://github.com/PyO3/maturin/blob/243b8ec91d07113f97a6fe74d9b2dcb88086e0eb/src/target.rs#L547
        let python_interpreter = match os {
            Os::Windows => PathBuf::from("python.exe"),
            Os::Linux | Os::Macos => {
                if env::var_os("VIRTUAL_ENV").is_some() {
                    PathBuf::from("python")
                } else {
                    PathBuf::from("python3")
                }
            }

View on GitHub (pinned to d16f7ba2ed)

Solutions

  1. Build normally through `cargo build`/`cargo check` so Cargo sets `CARGO_CFG_TARGET_OS`
  2. If using a custom build system, define the variable yourself: `CARGO_CFG_TARGET_OS=linux cargo build ...` (values: linux/windows/macos)
  3. Check that no wrapper script, `env -i`, or CI sandbox is stripping the environment before cargo runs
  4. Update cargo and burn-tch to current versions in case of a toolchain regression

Example fix

// before (custom wrapper)
rustc --crate-name burn_tch build.rs  # panics: no CARGO_CFG_TARGET_OS
// after
CARGO_CFG_TARGET_OS=linux cargo build -p burn-tch  # or just: cargo build
Defensive patterns

Strategy: fallback

Validate before calling

// shell check before building
[ -n "$CARGO_CFG_TARGET_OS" ] && echo ok || { echo 'not running under cargo'; exit 1; }

Try / catch

// This is a build-script panic; guard in the invoking script:
set -e
: "${CARGO_CFG_TARGET_OS:?CARGO_CFG_TARGET_OS not set — run via cargo build}"

Prevention

When it happens

Trigger: Compiling the `burn-tch` crate when `CARGO_CFG_TARGET_OS` is absent from the build script's environment — e.g. invoking `build.rs` manually with rustc, running inside a sandboxed/wrapped build harness that sanitizes env vars, misconfigured `cargo` custom wrappers, or CI tools that execute build scripts outside a normal `cargo build`.

Common situations: Custom Bazel/Buck or Docker build pipelines that call rustc directly; Cargo plugins that don't forward Cargo-provided env vars; broken toolchain installs; users patching or re-running build scripts by hand to debug libtorch linking.

Understand the failure class

Background: "environment variable is not set" and "Missing keys in environment" errors: what missing required env var messages mean and how to fix them — this error's family across 28 libraries.

Related errors


AI-assisted analysis of tracel-ai/burn@d16f7ba2ed (2026-09-05). Data as JSON: /api/errors/79bb8403052de1d8. Report an issue: GitHub.