# What dependencies go into a \`\[c\]dylib\`? **URL:** \ **Category:** cargo\ **Created:** [September 5, 2024, 10:39pm UTC](https://internals.rust-lang.org/t/what-dependencies-go-into-a-c-dylib/21489 "2024-09-05T22:39:17Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![fosterbrereton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fosterbrereton/32/12527_2.png) [@fosterbrereton](https://internals.rust-lang.org/u/fosterbrereton)\ **Post date:** [September 5, 2024, 10:39pm UTC](https://internals.rust-lang.org/t/what-dependencies-go-into-a-c-dylib/21489/1 "2024-09-05T22:39:17Z")
I am reading through the [linkage documentation](https://doc.rust-lang.org/reference/linkage.html) (which is very helpful), and I see this line in the `staticlib` section: > The purpose of this output type is to create a static library containing all of the local crate's code along with all upstream dependencies. However, `dylib` and `cdylib` do not mention what upstream dependencies they might include (native or otherwise). This is especially important for managing non-Rust dependencies that are implicitly included by Rust-built artifacts (e.g., making sure the boring-ssl brought in by `boring-sys` will jive with another component that also declares a need for it.) Can guarantees be made about what dependencies (if any) are included in `dylib` and `cdylib` artifacts? Can the documentation be updated to reflect those guarantees? ---
**Author:** ![CAD97](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/cad97/32/3460_2.png) [@CAD97](https://internals.rust-lang.org/u/CAD97)\ **Post date:** [September 5, 2024, 11:09pm UTC](https://internals.rust-lang.org/t/what-dependencies-go-into-a-c-dylib/21489/2 "2024-09-05T23:09:13Z")
`cdylib` bundles all Rust code and requires only any native dependencies, as like with `staticlib`. `dylib` is able to be later linked by `cargo`/`rustc`, but provides basically no guarantees beyond that and may have arbitrary other dependences that `cargo`/`rustc` will satisfy later when building a leaf crate (`bin` or `cdylib`). This [_is_ documented](https://doc.rust-lang.org/reference/linkage.html), even if not perfectly so; `dylib` is > A dynamic Rust library will be produced. This is different from the `lib` output type in that this forces dynamic library generation. The resulting dynamic library can be used as a dependency for other [Rust] libraries and/or executables. with the relevant part of `lib` being that it's usable by `rustc` to build downstream crates but it's otherwise unspecified how that happens, and `cdylib` is > A dynamic system library will be produced. This is used when compiling a dynamic library to be loaded from another language. i.e. it doesn't have any surprise dependencies that the other language wouldn't know how to provide. You can also get rustc to output a list of required native dependencies as part of the build process. ---
**Author:** ![fosterbrereton](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/fosterbrereton/32/12527_2.png) [@fosterbrereton](https://internals.rust-lang.org/u/fosterbrereton)\ **Post date:** [September 6, 2024, 3:05pm UTC](https://internals.rust-lang.org/t/what-dependencies-go-into-a-c-dylib/21489/3 "2024-09-06T15:05:14Z")
Thank you for the clarifications. I am going down the rabbit hole of integrating Rust-based components in large, complex build systems that are primarily C/C++ based. It would seem this path [has been well-trod already](https://github.com/rust-lang/rust/issues/73632), even though there doesn't seem to be formal acceptance of [the RFC that stabilizes the `rlib` format](https://internals.rust-lang.org/t/pre-rfc-stabilize-a-version-of-the-rlib-format/17558/1). > You can also get rustc to output a list of required native dependencies as part of the build process. My understanding from [the `--print` docs](https://doc.rust-lang.org/rustc/command-line-arguments.html#--print-print-compiler-information) is that flag is only available when building a `staticlib`. Furthermore, the native dependencies the crate uses aren't listed by `native-static-libs` because they are included in the `.a`. Is there another flag you were thinking of that would work for `rlib`? ---
**Author:** ![steffahn](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/steffahn/32/13288_2.png) [@steffahn](https://internals.rust-lang.org/u/steffahn)\ **Post date:** [February 28, 2026, 3:05pm UTC](https://internals.rust-lang.org/t/what-dependencies-go-into-a-c-dylib/21489/4 "2026-02-28T15:05:56Z")
This topic was automatically closed 540 days after the last reply. New replies are no longer allowed.