Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 8:54 UTC (Tue) by taladar (subscriber, #68407)
In reply to: Shared libraries by ballombe
Parent article: APT Rust requirement raises questions

Oddly enough none of the distros that advocate for this approach officially cover the part of that process that needrestart does, i.e. actually tell the user what needs to be restarted to get the benefit of that update.

to post comments

Shared libraries

Posted Nov 25, 2025 9:45 UTC (Tue) by leromarinvit (subscriber, #56850) [Link] (14 responses)

Is that so? My Debian and Ubuntu systems will often restart services after installing updates. Does this not cover shared library updates - i.e. is a service only restarted after it itself was updated? Genuinely curious, I've always just assumed dependencies would also trigger restarts (at least if they're shared libs).

If they don't, just setting APT to auto-install security updates, without somehow restarting individual services or the whole system afterwards, is clearly not enough to at least keep a system free of known (and fixed) vulnerabilities.

Shared libraries

Posted Nov 25, 2025 10:03 UTC (Tue) by taladar (subscriber, #68407) [Link]

There is that "Daemons using outdated libraries" thing that sometimes pops up but it only covers a small subset of the running binaries or even systemd services actually using updated files.

Shared libraries

Posted Nov 25, 2025 10:05 UTC (Tue) by epa (subscriber, #39769) [Link] (12 responses)

Yes, that's the shameful secret of security updates in shared libraries. We've long mocked the Microsoft approach of rebooting the device for every change, but it's hard to beat if you want to guarantee that the vulnerable code is no longer running anywhere on the system.

In principle a program could be re-linked against the new shared library code while it stays running, but that requires an even stronger ABI stability guarantee than most libraries provide.

Shared libraries

Posted Nov 25, 2025 11:26 UTC (Tue) by SLi (subscriber, #53131) [Link] (10 responses)

Hmm. Why is this a shared vs static library problem? Doesn't the application need to be restarted in either case to get the benefits?

Shared libraries

Posted Nov 25, 2025 14:02 UTC (Tue) by farnz (subscriber, #17727) [Link] (9 responses)

The claim being made for shared libraries is that I can just update the library, and all the applications are immediately patched, which reduces admin effort as compared to static linking, where I have to update the binaries and then restart the applications.

The point is that it's not that big a reduction in effort - and it's a reduction in effort in the automated part, to boot.

Shared libraries

Posted Nov 25, 2025 14:59 UTC (Tue) by intelfx (subscriber, #130118) [Link] (8 responses)

> The claim being made for shared libraries is that I can just update the library, and all the applications are immediately patched, which reduces admin effort as compared to static linking, where I have to update the binaries and then restart the applications.

Nobody is making the claim for shared libraries to somehow obviate the need to *restart the applications*. You invented this claim out of thin air.

Shared libraries obviate the need to *update the binaries*, no more, no less.

Shared libraries

Posted Nov 25, 2025 15:12 UTC (Tue) by farnz (subscriber, #17727) [Link] (7 responses)

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.

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.

Shared libraries

Posted Dec 6, 2025 10:38 UTC (Sat) by jengelh (subscriber, #33263) [Link]

>We've long mocked the Microsoft approach of rebooting the device for every change, but it's hard to beat if you want to guarantee that the vulnerable code is no longer running anywhere on the system

The more evolved and hostile attached networks became between 1990 and now, the *less* Windows versions needed to reboot. So it does not seem like the mocking was ever done because of (in)security concerns.

Shared libraries

Posted Nov 25, 2025 16:02 UTC (Tue) by draco (subscriber, #1792) [Link] (2 responses)

Officially, Fedora only supports offline updates (reboot, apply updates in constrained environment, then boot with updated software). You can do it online, but then it's up to you to pick up the pieces.

You keep saying distros don't handle this case, but they do.

Extra services during offline upgrade

Posted Nov 27, 2025 18:13 UTC (Thu) by DemiMarie (subscriber, #164188) [Link] (1 responses)

Is there a way to run extra services during an offline upgrade? Qubes OS requires that a VM be running certain services at all times.

Extra services during offline upgrade

Posted Nov 28, 2025 12:10 UTC (Fri) by neverpanic (subscriber, #99747) [Link]

AFAIR, the "offline" upgrade really is just a special systemd target that gets activated when a specific symlink exists in the rootfs, and a successful update deletes that symlink.

So, yes, you can run extra services by making sure your systemd service file is configured to start in that target.