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
- Switch to a supported 32- or 64-bit target triple for the pyo3 dependency
- Exclude pyo3/Python extension code from embedded targets (feature-gate it out of the workspace build for that target)
- 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
- Only compile pyo3 crates for 32- or 64-bit targets
- Feature-gate Python extension code out of embedded builds
- Validate custom target JSONs declare standard pointer widths
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
- Neither abi3 or abi3t features are enabled
- Cannot target an abi3t version below {MINIMUM_SUPPORTED_VERS
- failed to run the Python interpreter at {}: {}
- Python script failed
- cannot set a minimum Python version {} higher than the inter
AI-assisted analysis of PyO3/pyo3@ac9b6899d3 (2026-09-05).
Data as JSON: /api/errors/72d2eaf0c90b2f7c.
Report an issue: GitHub.