Shared libraries [LWN.net]

Shared libraries

Posted Nov 26, 2025 8:54 UTC (Wed) by taladar (subscriber, #68407)
In reply to: Shared libraries by nim-nim
Parent article: APT Rust requirement raises questions

On the other hand why is converging on a version that isn't the latest version a good thing? Shared library distro builds are essentially always stuck on the oldest version that some reverse dependency requires while static linking can just use the latest version, becoming part of the much, much larger group of people who aren't years behind.

This gets rid of all the effort required for distro specific bugs when developers don't want bug reports for ancient versions, all the backporting,...

to post comments

Shared libraries

Posted Nov 28, 2025 9:37 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (1 responses)

The latest version is not necessarily reliable, give the developers of other components a break, they also need to explore new approaches. Converging on a common version means a lot of people found this particular version reliable;

Static building is the opposite of using the latest version, people use the latest version *at the time they bother to check* and then lock it down and accumulate technical debt. People do not like making the effort to update, period, they can’t complain using dynamic libraries forces them to update on a regular cadence (that would expose that they do not want to make this effort) they complain that the update forced on them by distributions is not new and shiny enough.

Shared libraries

Posted Nov 29, 2025 16:20 UTC (Sat) by khim (subscriber, #9252) [Link]

> Converging on a common version means a lot of people found this particular version reliable;

That's only true for forges like PyPi or crates.io. Where people are free to pick any version they like.

With distros is the exact opposite: few packagers, often just one, single, person decides what version of library to package.

That's the opposite of the process that may lead to the outcome you describe.

> Static building is the opposite of using the latest version, people use the latest version *at the time they bother to check*

Still better than some random version that was picked by god-know-who for god-know-what reason and which wasn't even tested in conjunction with app.

> they complain that the update forced on them by distributions is not new and shiny enough.

People complain when something doesn't work, period. It may be too new or too old or anything in between.

But with distros they are often in position that they have no one to even complain to because person that assembled the crazy combination of libraries that breaks things is not even result of conscious decision, but more of result of random dice throwing.

According to the distro makers every package should be ready to work with every version of library… but that's rarely a thing that any sane developer would accept: to know whether something works or not you need to test… and distro makers make that exceedingly difficult.

Shared libraries

Posted Nov 28, 2025 11:25 UTC (Fri) by intelfx (subscriber, #130118) [Link] (1 responses)

> Shared library distro builds are essentially always stuck on the oldest version that some reverse dependency requires while static linking can just use the latest version, becoming part of the much, much larger group of people who aren't years behind.

Yeah, that's just the exact opposite of how it happens in reality.

In reality, applications in ecosystems with vendor-controlled static linking/bundling/vendoring get locked to the first version of each dependency that happens to work and never upgraded again (until a vulnerability is exploited in the wild, or until maintenance of a suitably obsolete build environment becomes untenable through actions of others).

Maintainers of distributions, on the other hand, care about health of the overall "ecosystem" Of course, the quality of said care may differ, but the overall concept is always there. You, as a user, may be briefly stuck on non-latest versions (or even on legacy branches) of some dependencies, but the entire distribution moves forward as fast as manpower allows.

Shared libraries

Posted Dec 1, 2025 9:59 UTC (Mon) by taladar (subscriber, #68407) [Link]

That is the way it works in C/C++ when they vendor dependencies because the tooling to upgrade sucks but e.g. on Rust, when upgrading dependencies is as simple as running cargo upgrade and cargo update and then fixing the minor compile issues 99% of the time (i.e. every time some dependency didn't completely revamp their API which is very rare) keeping up with dependency versions is incredibly easy.