3 ms·

While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise oc

While statically linking most certainly has its use-cases (as the parent comment pointed out), it unjustifiably presents challenges that would not otherwise occur. To elaborate on the parent's example: a particularly bad bug in a library depended on by a set of programs might not cause much of problem if you build and deploy this software yourself. However, it would be a more significant endeavor on both the distribution's part (recompile, repackage, sign-off, and release every program in the set), and on the user's part who has to download the large binaries each time a dependency is updated rather than a small library. This problem is further exacerbated by the npm-like dependency graphs rust programs tend to end up with. Take servo as an extreme example of what these graphs might look like: https://web.archive.org/web/20160703132700/https://dirkjan.ochtman.nl/files/servo-graph.svg https://web.archive.org/web/20160703132700/https://dirkjan.o... Furthermore, I don't see how dynamic linking prevents the compiler from optimizing the resulting binaries. C libraries have been dynamically linked for decades without issue.

snuxoll 10y ago
You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.
- deleted 10y ago
  [deleted]
evmar 10y ago
Now I'm imagining Fedora building one rpm per crate in servo -- that picture has like 50 of em, heh.
- snuxoll 10y ago
  What else is new? Have you seen the package database recently?

snuxoll 10y ago

You forgot an important step: recompile, repackage, TEST, sign-off, and release every program in the set. Updates in Fedora sit in updates-testing for a week unless the package gets enough karma from users testing the package, there's a fast track for certain security updates but having to push dozens of packages that depend on a library through this is a giant pain and causes a huge headache. With dynamic libraries we can just update the library, get it through the testing phase (and if necessary fast track a single update) and move on with life. As far as the GP's point about optimization, rustc can inline a lot of code from linked crates if you are compiling statically, which in tight loops can be a very useful performance optimization due to not needing to spend cycles on setting up a new stack frame and calling the function. However, like you say, applications written in C/C++ have used dynamic linking for ages and it is usually quite rare to need optimizations this deep - if YOU need them for your application please feel free, but in general dynamic linking should still be preferred.

deleted 10y ago
[deleted]

evmar 10y ago

Now I'm imagining Fedora building one rpm per crate in servo -- that picture has like 50 of em, heh.

snuxoll 10y ago
What else is new? Have you seen the package database recently?