Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 15:12 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Shared libraries by intelfx
Parent article: APT Rust requirement raises questions

They don't even do that - you have to update the binaries that are supplied by the shared library, and the in-memory copies of the binaries, too.

The only thing they do is mean that you don't have to replace the executables - but replacing binaries (libraries or executables) is the bit of the update process that's simple to automate.

to post comments

Shared libraries

Posted Nov 25, 2025 18:23 UTC (Tue) by intelfx (subscriber, #130118) [Link] (6 responses)

Clearly, "updating the binaries" in this argument means updating the _dependent_ binaries (the executables). I intended to include this clarification but omitted it due to sheer obviousness.

> but replacing binaries (libraries or executables) is the bit of the update process that's simple to automate.

It's not so simple (or cheap) to automate _creating_ those binaries in the first place. This is the part shared libraries help with: you do not need to rebuild and redistribute O(n) dependents when all you need is to make a compatible change in O(1) libraries.

Shared libraries

Posted Nov 25, 2025 19:14 UTC (Tue) by NYKevin (subscriber, #129325) [Link] (5 responses)

> It's not so simple (or cheap) to automate _creating_ those binaries in the first place.

The argument made by the newer languages is that it should be. And they have largely succeeded. When is the last time you saw a Rust or Go project that *couldn't* be built with cargo build, go build, etc.?

Yes, yes, the subsequent packaging step is frequently more complicated. But that step is entirely the distro's invention. They don't get to make it everyone else's problem.

Shared libraries

Posted Nov 28, 2025 3:16 UTC (Fri) by wtarreau (subscriber, #51152) [Link] (4 responses)

This full rebuild of applications however is a real problem for end users because they cannot choose anymore to only update the part that causes trouble. When application X has dependency Y and a full rebuild of X+Y has to be done to fix Y, most of the time it also comes with fixes (or even minor updates) of X, that users have to accept just to fix Y. This is a real problem because regressions do happen (frequently) and the more dependencies are involved in a rebuild, the more likely unintended changes are visible to the end user, who don't always have the choice of running the software that works for them and only update problematic dependencies.

Shared libraries

Posted Nov 28, 2025 5:35 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link]

I keep reminding people here that Gentoo exists. And it's not a new fad, it's been around for more than two decades. And Nix is a newer example.

Shared libraries

Posted Nov 28, 2025 8:33 UTC (Fri) by taladar (subscriber, #68407) [Link] (2 responses)

You mean they don't get a choice in the way they don't get a choice to keep the old version of a shared library (or indeed choose an arbitrary version of a shared library) for each of the other applications using that same library on the system that might not be affected by a fix?

Besides, updating all the dependencies to the same combination of dependency versions used by everyone else using the application actually reduces the number of truly different combinations in use, making it more likely that someone else is running the same version and has run into a bug before you do.

Shared libraries

Posted Jan 14, 2026 4:48 UTC (Wed) by wtarreau (subscriber, #51152) [Link] (1 responses)

> You mean they don't get a choice in the way they don't get a choice to keep the old version of a shared library (or indeed choose an arbitrary version of a shared library) for each of the other applications using that same library on the system that might not be affected by a fix?

No I mean they don't have the choice to only updating the library without updating the application. The lifecycle of applications is not always the same as that of libraries. Take firefox as an example, you might experience issues caused by one of the thousand libs it depends on, but otherwise match your needs. By only updating that broken lib you get a perfectly functional browser. When using static builds, it's less likely that they'll rebuild your version based on an updated dependency so instead you're more likely to be forced to upgrade to the next version that probably doesn't please you at all anymore, or introduces new issues. The alternative is to not update the static application and that's an issue with security stuff (e.g. crypto libraries), which will overall degrade the security of what's effectively deployed in the field.

Shared libraries

Posted Jan 14, 2026 5:20 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

The corollary is that if you have a static version, it's usually easy to build a custom version, because the project will have tooling to easily manage the bundled libraries. Otherwise they'd go mad.

This absolutely applies to Rust and Go. I can make my own mini-fork within minutes for most of the projects, except for really hairy ones like Docker or K8s.