rust-lang/cargo · error

library ` ` cannot set the crate type of both `dylib` and…

Error message

library `{}` cannot set the crate type of both `dylib` and `cdylib`

What it means

A library target's `crate-type` may not list both `dylib` (a Rust-ABI dynamic library loaded by other Rust crates) and `cdylib` (a C-ABI dynamic library for FFI). They produce incompatible symbol/export layouts, so the match arm at targets.rs:247-252 rejects the combination outright before any compilation.

Solutions

  1. Choose `cdylib` if the consumer is C/FFI; choose `dylib` if the consumer is another Rust crate.
  2. If you truly need both ABIs, split into two crates or two `[lib]` targets with distinct names and paths.
  3. Use `cargo build` to confirm the single type resolves.

Example fix

# before
[lib]
crate-type = ["dylib", "cdylib"]

# after (C/FFI consumer)
[lib]
crate-type = ["cdylib"]
Defensive patterns

Strategy: validation

Validate before calling

fn lib_has_conflicting_crate_types(crate_types: &[String]) -> bool {
    crate_types.iter().any(|t| t == "dylib")
        && crate_types.iter().any(|t| t == "cdylib")
}

Prevention

When it happens

Trigger: Cargo.toml has `[lib] crate-type = ["dylib", "cdylib"]` (in any order). The guard `kinds.contains(&Dylib) && kinds.contains(&Cdylib)` matches and bails.

Common situations: Wanting both a Rust-loadable and a C-callable artifact from one crate and naively listing both. Copy-pasting crate-type lists between unrelated projects. Misunderstanding that cdylib already produces a loadable `.so`/`.dylib`/`.dll`.

Related errors


AI-assisted analysis of rust-lang/cargo@eb98b54bc9 (2026-08-11). Data as JSON: /api/errors/101dad83b6438b9d. Report an issue: GitHub.

Appendix: source

Thrown at src/workspace/parser/targets.rs:247

    let path = lib.path.as_ref().expect("previously normalized");
    let path = package_root.join(&path.0);

    // Per the Macros 1.1 RFC:
    //
    // > Initially if a crate is compiled with the `proc-macro` crate type
    // > (and possibly others) it will forbid exporting any items in the
    // > crate other than those functions tagged #[proc_macro_derive] and
    // > those functions must also be placed at the crate root.
    //
    // A plugin requires exporting plugin_registrar so a crate cannot be
    // both at once.
    let crate_types = match (lib.crate_types(), lib.proc_macro()) {
        (Some(kinds), _)
            if kinds.contains(&CrateType::Dylib.as_str().to_owned())
                && kinds.contains(&CrateType::Cdylib.as_str().to_owned()) =>
        {
            anyhow::bail!(format!(
                "library `{}` cannot set the crate type of both `dylib` and `cdylib`",
                name_or_panic(lib)
            ));
        }
        (Some(kinds), _) if kinds.contains(&"proc-macro".to_string()) => {
            warnings.push(format!(
                "library `{}` should only specify `proc-macro = true` instead of setting `crate-type`",
                name_or_panic(lib)
            ));
            if kinds.len() > 1 {
                anyhow::bail!("cannot mix `proc-macro` crate type with others");
            }
            vec![CrateType::ProcMacro]
        }
        (Some(kinds), _) => kinds.iter().map(|s| s.into()).collect(),
        (None, Some(true)) => vec![CrateType::ProcMacro],
        (None, _) => vec![CrateType::Lib],
    };

View on GitHub (pinned to eb98b54bc9)