PyO3/pyo3 · error

unexpected Rust target pointer width: {}

Error message

unexpected Rust target pointer width: {}

What it means

During configuration pyo3-ffi compares the Rust target's pointer width (from CARGO_CFG_TARGET_POINTER_WIDTH) against the Python interpreter's pointer width. If cargo reports a pointer width other than 64 or 32, the value is unrecognized and the build bails, since pyo3 only supports 32- and 64-bit targets.

Source

Thrown at pyo3-ffi/build.rs:181

                "GraalPy does not support {abi} so the build artifacts will be version-specific."
            ),
            PythonImplementation::RustPython => {}
        }
    }

    Ok(())
}

fn ensure_target_pointer_width(interpreter_config: &InterpreterConfig) -> Result<()> {
    if let Some(pointer_width) = interpreter_config.pointer_width() {
        // Try to check whether the target architecture matches the python library
        let rust_target = match cargo_env_var("CARGO_CFG_TARGET_POINTER_WIDTH")
            .unwrap()
            .as_str()
        {
            "64" => 64,
            "32" => 32,
            x => bail!("unexpected Rust target pointer width: {}", x),
        };

        ensure!(
            rust_target == pointer_width,
            "your Rust target architecture ({}-bit) does not match your python interpreter ({}-bit)",
            rust_target,
            pointer_width
        );
    }
    Ok(())
}

/// `raw-dylib` currently does not support arbitrary names
/// (see https://internals.rust-lang.org/t/support-renames-with-link-name-kind-raw-dylib/24415)
/// so if the lib name is not one of the known subset, we must fall back to full linking.
fn lib_name_is_known_for_raw_dylib(lib_name: &str) -> bool {
    // pyo3_dll cfg for raw-dylib linking on Windows
    if matches!(

View on GitHub (pinned to ac9b6899d3)

Solutions

  1. Switch to a supported 32- or 64-bit target triple for the pyo3 dependency
  2. Exclude pyo3/Python extension code from embedded targets (feature-gate it out of the workspace build for that target)
  3. If using a custom target JSON, change its pointer width to 32 or 64 as appropriate

Example fix

// before
cargo build --target msp430-none-elf   # 16-bit
// after
cargo build --target x86_64-unknown-linux-gnu
Defensive patterns

Strategy: validation

Validate before calling

// shell
RUSTC_TARGET=<your-triple>; PW=$(rustc --print target-spec-json -Z unstable-options --target $RUSTC_TARGET 2>/dev/null | grep -o '"data-layout"' >/dev/null && echo check || echo check); rustc --print cfg --target $RUSTC_TARGET | grep target_pointer_width

Prevention

When it happens

Trigger: ensure_target_pointer_width (called from configure_pyo3_ffi) reads CARGO_CFG_TARGET_POINTER_WIDTH and hits an unexpected value like '16' — i.e. compiling for a niche 16-bit target, or a toolchain/custom target spec reports a nonstandard pointer width.

Common situations: Cross-compiling for embedded/16-bit Rust targets (e.g. some AVR-style custom targets); using a nightly custom target JSON with an unusual pointer width; misconfigured build environments where the env var is clobbered.

Related errors


AI-assisted analysis of PyO3/pyo3@ac9b6899d3 (2026-09-05). Data as JSON: /api/errors/72d2eaf0c90b2f7c. Report an issue: GitHub.