Why are Rust shared libraries not shipped with popular OS?

Why are Rust shared libraries not shipped with popular OS? Is it possible for it to happen once the language gains more traction?

It will help reduce Rust binary size.

Which shared libraries? If you're talking about Rust's standard libraries then I don't think this is a realistic option until Rust has a stable ABI (if that ever happens...).

The standard library only works with a single rustc version as the rust abi is unstable and the standard library depends on implementation details of rustc. (And the other way around, rustc depends on implementation details of the standard library.)

1 Like

Given the mess that is Redistributing Visual C++ Files | Microsoft Docs, it's not obvious to me that trying to have a single shared thing installed system-wide is a good thing -- especially since rust updates as frequently as it does.

An option to have something sharable between a bunch of different binaries that are all shipped together would be nice, though.

6 Likes

Another important note is that Rust binaries are fully statically linked by default (except where they talk to the OS, of course), as opposed to the dynamic linking to e.g. platform libc. This is useful to the optimizer to strip out abstraction cost, at the expense of binary size.

Additionally, static linking means that you don't have to worry about if downstream has an incompatible version of the shared library that you're relying on, and that even for compatible APIs, you know that some correctness fix you rely on is provided by your statically linked version.

(Static versus dynamic linking is a complicated topic, and there are tradeoffs to be made in either direction, so I'll leave that there. It's not as simple as providing a shared rlibstd.dll and profiting in smaller exe sizes.)

And maybe more importantly, a shared std wouldn't even help as much as you'd maybe think, because of generics. If you know how C++ templates work, generics work much the same way: their definition is inlined into every compilation unit (min. 1/crate, typ. 1/core/crate), and as such every call that is generic won't be shared in a shared library.


All of that said, while I do think that fully static linking is a good default and should stay the default, even in a future with fully stable Swift-style generics-supporting ABI (hard, and not zero overhead), cargo can and should support sharing dynamic libs between binaries that are deployed together better. (And that wouldn't even have to wait for said unicorn of an ABI, it could happen now for multiple binaries in the same workspace.)

2 Likes

Rust is not ready for this:

  • It hasn't declared its ABI to be stable and ready for shipping.
  • Rust uses monomorphised generics a lot, and they're a poor fit for shared libraries. Using them with shared libraries is either a compatibility hazard (if they're instantiated in the executables) or a big performance hit (if they're changed to dynamic dispatch).
2 Likes

For other methods to reduce binary size see: GitHub - johnthagen/min-sized-rust: 🦀 How to minimize Rust binary size 📦

Link Time Optimization (LTO) is especially useful for removing unused code from dependencies.

2 Likes

thanks. I was just curious since C does that.