4 ms·

Static Linking vs Dynamic Linking is a choice that has tradeoffs. If you only consider what's good about dynamic linking and ignore its shortcomings, sure: dyna

Static Linking vs Dynamic Linking is a choice that has tradeoffs. If you only consider what's good about dynamic linking and ignore its shortcomings, sure: dynamic linking is The Right Choice! But I see no mention of those tradeoffs. Examples: what if the system-provided library is old or has bugs? What if you're delivering to multiple distributions (or even OSes) and you need a consistent behaviour? What if you need different versions of a library?

baby 6y ago
What if you need to instrument these libraries?
cortesoft 6y ago
Yeah, this article seems a bit disingenuous... it says "I will prove there are no benefits to static linking!", but then goes on just to mention positives about dynamic linking. It never even mentions the reasons why people choose static linking, let alone attempt to refute them.
silvestrov 6y ago
also: What if the 1.0.1 version of the library isn't 100% compatible with the 1.0.0 and the app now crashes? Semantic versioning is nice in theory, but you can't rely on everybody getting in 100% correct and not introducing obscure bugs due to slightly different memory layout of structs. It also makes testing apps more difficult as you now doesn't know exactly what code the clients are running as there can be an incredible high number of permutations of library versions. Dynamic linking also makes it impossible to do link-time optimizations (e.g. inlining, dead-strip, locating code near the function that calls it)
rbarrois 6y ago
I'd say that the deal is: - With Dynamic Linking, it's the job of the system admin (typically a distribution maintainer) to ensure that the system-provided library and application are compatible — and add patches if needed; - With Static Linking, the package developer takes control of the whole experience; they deem more important to deliver a working application to the end user than to ensure compatibility with an OS. This makes sense for isolated applications, e.g. video games. For a system's core stack (coretools, X11, etc.), the end user expects to receive security fixes in a timely manner. From the distribution's point of view, it seems simpler to have a single library to patch, recompile and push, than to have the maintainer of each package statically linked against said library release an updated version...

baby 6y ago

What if you need to instrument these libraries?

cortesoft 6y ago

Yeah, this article seems a bit disingenuous... it says "I will prove there are no benefits to static linking!", but then goes on just to mention positives about dynamic linking. It never even mentions the reasons why people choose static linking, let alone attempt to refute them.

silvestrov 6y ago

also: What if the 1.0.1 version of the library isn't 100% compatible with the 1.0.0 and the app now crashes? Semantic versioning is nice in theory, but you can't rely on everybody getting in 100% correct and not introducing obscure bugs due to slightly different memory layout of structs. It also makes testing apps more difficult as you now doesn't know exactly what code the clients are running as there can be an incredible high number of permutations of library versions. Dynamic linking also makes it impossible to do link-time optimizations (e.g. inlining, dead-strip, locating code near the function that calls it)

rbarrois 6y ago

I'd say that the deal is: - With Dynamic Linking, it's the job of the system admin (typically a distribution maintainer) to ensure that the system-provided library and application are compatible — and add patches if needed; - With Static Linking, the package developer takes control of the whole experience; they deem more important to deliver a working application to the end user than to ensure compatibility with an OS. This makes sense for isolated applications, e.g. video games. For a system's core stack (coretools, X11, etc.), the end user expects to receive security fixes in a timely manner. From the distribution's point of view, it seems simpler to have a single library to patch, recompile and push, than to have the maintainer of each package statically linked against said library release an updated version...