Description
Once #10528 lands, we will have added static linking to rust. The caveat is that linking requires everything to be static or everything to be dynamic. This is not ideal, because one can easily think of cases where a dynamic library has static rust dependencies.
The major problem when doing this is to ensure that only one copy of a library shows up in the final result. For example, you can't statically link libstd to a dynamic library and then also statically link it into an executable.
This would probably involve encoding into the metadata what rust libraries were used, but this is not an easy change right now. The metadata is encoded into the object file that LLVM produces, and we use that same object file to produce the outputs desired by the compilation (you can simultaneously output an rlib and a dylib without having to recompile). Perhaps this is another case for separate metadata files? (libfoo.rlib.metadata and libfoo.dylib.metadata or something like that).
Regardless, the compiler should emit an error when it detects two versions of a rust library being available in the final executable, and it should also make it difficult for that to happen. This will likely involve altering how you declare dependencies to rust libraries.
The main use case that I have in mind is that a rust build dependency of a dynamic library should not need to get distributed. For this, perhaps the dynamic library declares its dependency on the rust build dependency declaring that it must statically link to that, but dynamic linking still favors linking to libstd dynamically (just as an example).
Regardless, this type of mixing of libraries should be possible in one form or another, and this probably means giving crates fine-grained controls over whether their dependencies are dynamic or static and then having reasonable defaults (and all of this is coupled with error messages on behalf of the compiler).