I am reading through the linkage documentation (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?
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, 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.
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, even though there doesn't seem to be formal acceptance of the RFC that stabilizes the rlib format.
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 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?