[davidwf]

This is very situational, but I have recently been part of a project that does a lot of C server-side development and we have found that static linking our non-glibc dependencies has really improved our developer experience. Using ceedling's dependency plugin[1] and producing a single "statically" linked library has made our C development much closer to using a language with a more modern package manager. Don't get me wrong, if I was trying to distribute binaries to machines I didn't control I'd definitely be willing to invest in the Linux packaging "fun", but for a server-side application it's been a good choice for our team overall.

[1] https://github.com/ThrowTheSwitch/Ceedling/tree/master/plugi...

[PaulDavisThe1st]

Yes and no. In Ardour, which has a substantial dependency tree (80+ libraries), if we statically link, the edit/compile/debug cycle becomes incredibly bogged down by static linkage. It takes a long time (even with lld) to complete the link step. If we use shared libraries/dynamic linkage, the edit/compile/debug cycle is nice and fast, but application startup is a bit slower (not by as much as static linkage is slower, however).

For users, it would be better if the application was statically linked, at least in terms of startup cost. But because developers do the edit/compile/debug cycle much, much more often than users start the application, we opt for dynamic linkage.

[xyzzyz]

You can dynamically link during development, and then ship statically linked binary (with LTO etc). That’s what Chrome does, for example.

[PaulDavisThe1st]

It's not that simple for us (we have tried this).