rust-lang/rust · critical

unsupported arch {arch}

Error message

unsupported arch {arch}

What it means

Thrown on the non-MSVC Windows path that invokes binutils dlltool to build an import library. The match maps arch to dlltool's -m target architecture string and only handles X86_64, X86, AArch64 and Arm. Any other arch passed to this GNU/MinGW import-library path panics because dlltool has no known flag set for it. Reached when is_like_msvc is false but the target still requires a Windows import library.

Source

Thrown at compiler/rustc_codegen_ssa/src/back/archive.rs:234

        }
    };

    // --no-leading-underscore: For the `import_name_type` feature to work, we need to be
    // able to control the *exact* spelling of each of the symbols that are being imported:
    // hence we don't want `dlltool` adding leading underscores automatically.
    let dlltool = find_binutils_dlltool(sess);
    // temp_prefix doesn't handle paths with spaces so
    // use a relative path and set the current working directory
    let cwd = output_path.parent().unwrap_or(output_path);
    let temp_prefix = lib_name;
    // dlltool target architecture args from:
    // https://github.com/llvm/llvm-project-release-prs/blob/llvmorg-15.0.6/llvm/lib/ToolDrivers/llvm-dlltool/DlltoolDriver.cpp#L69
    let (dlltool_target_arch, dlltool_target_bitness) = match &sess.target.arch {
        Arch::X86_64 => ("i386:x86-64", "--64"),
        Arch::X86 => ("i386", "--32"),
        Arch::AArch64 => ("arm64", "--64"),
        Arch::Arm => ("arm", "--32"),
        arch => panic!("unsupported arch {arch}"),
    };
    let mut dlltool_cmd = std::process::Command::new(&dlltool);
    dlltool_cmd
        .arg("-d")
        .arg(def_file_path)
        .arg("-D")
        .arg(lib_name)
        .arg("-l")
        .arg(&output_path)
        .arg("-m")
        .arg(dlltool_target_arch)
        .arg("-f")
        .arg(dlltool_target_bitness)
        .arg("--no-leading-underscore")
        .arg("--temp-prefix")
        .arg(temp_prefix)
        .current_dir(cwd);

View on GitHub (pinned to 22057b88b0)

Solutions

1. Target a supported MinGW arch triple such as x86_64-pc-windows-gnu or i686-pc-windows-gnu.
2. If the target is genuinely MSVC, set is_like_msvc=true so the native ar_archive_writer path (archive.rs:125) is taken rather than dlltool.
3. To support a new arch, add the (dlltool_target_arch, bitness) pair at compiler/rustc_codegen_ssa/src/back/archive.rs:229.

fn archive_arch_supported(arch: &str) -> bool {
    const OK: &[&str] = &[
        "x86_64", "i686", "i586", "aarch64", "arm", "armv7",
        "powerpc", "powerpc64", "powerpc64le", "s390x",
        "riscv64", "riscv32", "mips", "mips64", "sparc",
        "sparc64", "wasm32", "msp430", "nvptx64",
    ];
    OK.contains(&arch)
}

fn is_supported_archive_arch(arch: &str) -> bool {
    !arch.is_empty() && archive_arch_supported(arch)
}

let s = String::from_utf8_lossy(&output.stderr);
if s.contains("unsupported arch") {
    return Err(LinkError::UnsupportedArch(arch.into()));
}

When it happens

Trigger: Building a staticlib/cdylib for a MinGW/GNU Windows target (e.g. *-pc-windows-gnu) whose arch is not X86_64/X86/AArch64/Arm, so dlltool lacks a -m argument. Also reachable via a custom target spec mislabeled as GNU Windows with an exotic arch.

Common situations: Custom windows-gnu target JSON with an unsupported arch. Cross-compiling to windows-gnu on a non-x86/arm architecture that dlltool does not understand. Toolchain drift where a new arch was added to rustc_target but not to this match.

Related errors

• unsupported cpu type {cpu}
• LLVM error: {}
• wanted an rlib
• corrupt rlib
• archive member at offset {start} with size {} exceeds archiv

AI-assisted analysis of rust-lang/rust@22057b88b0 (2026-08-03). Data as JSON: /data/errors/9693c0791b978b2e.json. Report an issue: GitHub.