https://doc.rust-lang.org/reference/linkage.html #4 seems to imply that dynamically linked rust crates would be available in the cdylib case, though it just says dynamic library, so perhaps it refers only to rust dylibs.
https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/dependency_format.rs#L79 indicates otherwise, stating that both staticlibs and cdylibs must have all static rust crates.
In my group's use case, it is important that memory usage be kept to a minimum. One way we intended to tackle this was for the standard library (and other components, but the standard library is an obvious large piece) to have their code size costs amortized across all the places it is linked in by using dynamic linking. Unfortunately, we also intended to use cdylibs to gradually introduce Rust into a mostly C++ codebase, and these two concerns are now at odds.
Is there a rationale for this decision, or is support simply unimplemented? The potential issues I can see are:
If these are non-issues, we could consider allowing dynamic linking in general for staticlibs and cdylibs, but still defaulting to static linking for ease of use.
If some of these are potential issues, we could possibly mask this off at the Cargo layer (because separately combining cdylibs with dynamic linkage from two cargo invocations could lead to some of the issues above), but allow it at the rustc layer so that monolithic build systems could use this functionality.
I'd also love to hear about any other gotchas you think we might run into if we tried to do dynamic linkage of rust crates into a cdylib.
I am so close to diving in and trying to force myself to explore all the points in this design space. (And how would I force myself to do so? In my usual fashion: By composing a blog post that takes me a month to write...!)