Static and dynamic libraries

Generally, Rust dependencies have two types of linking:

• Static: Via the rlib format.
• Dynamic: Via shared libraries (.so or .dll).

The preference—if a corresponding rlib can be found—is to link statically and therefore include all dependencies into the output binary, making the file a lot larger (to the dismay of embedded programmers). Therefore, if multiple Rust programs use the same dependency, each comes with its own built-in version. It's all about the context though, since, as Go's success has shown, static linking can simplify complex deployments since only a single file has to be rolled out.

There are drawbacks to the static linking approach beyond size: for static libraries, all dependencies have to be of the rlib type, which is Rust's native package format, and cannot contain a dynamic library since the formats (for example, .so (dynamic) and .a (static) on ELF systems) aren't convertible.

For Rust, dynamic linking is commonly used for native dependencies, since they are usually available in the operating system and don't need to be included in the package. The Rust compiler can favor this with a -C prefer-dynamic flag, which will get the compiler to look for the corresponding dynamic libraries first.

Therein lies the current strategy of the compiler: depending on the output format (--crate-format= rlib, dylib, staticlib, library, or bin), it decides on the best linking type with your influence via flags. However, there is a rule that the output cannot statically link the same library twice, so it won't link two libraries with the same static dependency.

For more information on the topic, we recommend checking out https://doc.rust-lang.org/reference/linkage.html. That said, the compiler is usually trustworthy and, unless there is an interoperability goal, rustc will decide optimally.