Dynamic linking by default has been vocally criticized by everyone from Carmack to Bell Labs/Plan9/golang people. Many if not most of the big scale companies have historically avoided it like the plague. It has horrific costs in performance, security, reproducibility, and ultimately comprehensibility of any system.

People pay out the ass in droves via Docker (huge-ass images, clunky composability, cgroup/namespace complexity) and Nix (horror-movie learning curve) and I'm sure other things to get around it / emulate static linking. `sudo apt-whatever upgrade` and pray is pretty much DOA in even low-complexity settings. People are voting with their feet.

You can disagree, and if you're not affiliated with Debian or GNU I might even believe that you come by that opinion honestly, but this gigantic bloc of people who hate it are not all "oblivious".

> Docker

It's strange when an app is packaged with its own private copy of all of the "shared" libraries that it uses.

Many apps that could be a single static binary seem to be packaged as docker images largely for dependency inclusion and some cgroup/namespace isolation.

Bell Labs introduced shared objects into UNIX, maybe they should have learned better from other platforms.

They realized that they had goofed like 25-30 years ago and have been battling their own monster ever since: http://harmful.cat-v.org/software/dynamic-linking/versioned-....

I take the authors of a disaster more seriously when they say it's a disaster, not less.

And yet the same authors designed Inferno and Limbo, where dynamic loading is everywhere, even at language level.

Talk about being serious.

You gave it away by saying "dynamic loading" instead of "dynamic linking". They're okay with one, but not the other.

Very few use cases that involve deliberately avoiding static linking these days imo.

I'd say this is a solved problem. It's easy to get all build dependencies of a package and for every library that gets updated you build the world.

It's a more computing power and bandwidth that is required, but the maintenance burden is mostly solved by now by modern package managers or tooling on top of not so modern ones.

I like the old school days of just building everything from source. Similarly the Linux Kernel was statically built -- before modules. I knew the whole system from top to bottom.

If there was a standard for specifying which static library a binary has linked, this would be a non-issue.

> If there was a standard for specifying which static library a binary has linked, this would be a non-issue.

You just gave a non-sequitur answer that rings as rational and true as stating that if the Pope would fly he would be an Airbus A330.

Limiting which static library you can link to means absolutely nothing to the problems created by static linking, and how shared libraries solve all of them without any meaningful tradeoff at all.

In a sense there kinda is.

Pre-linking is a way to statically specify the lookup for a given shared library in an ELF executable. It's still kinda dynamic linking because the file is loaded at runtime but there's no library lookup, it's just "load this file at this path into address space while we load the rest of the main executable". Before PIC there would have been a bit more of a distinction but nowadays static and dynamic libraries are really only distinguished by where the symbols are (unless you want to be able to dynamically load and unload after startup).

Dynamic linking is just poor man's IPC.