DeVault: Announcing the Hare programming language [LWN.net]

DeVault: Announcing the Hare programming language

Posted May 4, 2022 13:31 UTC (Wed) by wtarreau (subscriber, #51152)
In reply to: DeVault: Announcing the Hare programming language by ilammy
Parent article: DeVault: Announcing the Hare programming language

> The purported argument for shared libraries is that “distro maintainers” (= people who are not us) are going to take care of the updates, so that we don’t have to rebuild and update our applications. But who’s going to install these updates to shared libraries?

No that's not the main point. The main point is that you can limit the amount of stuff you have to replace. When you upgrade your libc to get rid of the ghost vulnerability, all your executables are fixed at once. When they're all static, you have to replace all your executables with the ones the distro vendor had nicely rebuilt for you. And that can take quite some time when there are lots of packages, up to several days for mainstream distros, which will significantly delay the deployment of the fix in field. In addition it means that when there are multiple vendors (local builts counting as a "vendor" as well), it then becomes extremely difficult to make sure the system is fixed.

But fixes deployment is an entire class of problems on its own, there's no single nor excellent solution, there are pros and cons everywhere. Shared libs come with a number of cons but none of them is dramatic, and a number of pros that can keep you out of the mud. Static libs tend to navigate between much worse and much better, and will occasionally leave you a bad feeling.

to post comments

DeVault: Announcing the Hare programming language

Posted May 4, 2022 15:11 UTC (Wed) by farnz (subscriber, #17727) [Link]

It's a trade-off. Shared linking forces you to consider backwards and forwards compatibility in your ABI, where static linking permits you to get away with only caring about API.

Static linking also enables library consumers to simply test for the behaviour they expect; with shared linking, you need to be confident that the set of library behaviour you depend upon is by design, and not a happy accident. If you don't take the ABI contracts seriously (on either side of the ABI), then you get broken by mistake as an implementation detail you happened to care about changes.

Tooling to help get this right sort-of exists (abidiff for example), but it's more than just the things that can be checked by tooling that matter - for example, if I change a library so that you now need to call mylib_free on a pointer I returned, where previously free worked, you're going to be surprised.