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
- Choose `cdylib` if the consumer is C/FFI; choose `dylib` if the consumer is another Rust crate.
- If you truly need both ABIs, split into two crates or two `[lib]` targets with distinct names and paths.
- 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
- Choose one dynamic crate type per lib target.
- Split dual-ABI needs into separate crates.
- Review `crate-type` lists during code review.
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
- can't find library ` `, rename file to `src/lib.rs` or…
- cannot mix `proc-macro` crate type with others
- library target names cannot contain hyphens
- cannot compile ` ` as the target ` ` does not support any…
- cannot produce for ` ` as the target ` ` does not support…
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)