Shared libraries [LWN.net]

Shared libraries

Posted Nov 24, 2025 18:48 UTC (Mon) by hunger (subscriber, #36242)
In reply to: Shared libraries by ballombe
Parent article: APT Rust requirement raises questions

> C++ support shared libraries and rust could in principle support them too.

Does it? Yes, it works most of the time, but that is by luck and not by design.

The headers used to build some binary contain lots of code that gets backed into the binary (e.g. all templates). If any of those get changed by the next version of the library, then you can spent fun times debugging crashes as suddenly the code baked into the binary from the old version fails to use some symbol backed into the new library.

There is a reason why most distros rebuild binaries when the dependencies change.

Yes, rust could do the same. Rust has a different culture so it won't.

to post comments

Shared libraries

Posted Nov 25, 2025 2:22 UTC (Tue) by Elv13 (subscriber, #106198) [Link] (3 responses)

The same is true for C, but the ABI surface is smaller. `enum SecurityMode {LEGACY, SECURE, DISABLED};` sometime accidentally switch to `enum SecurityMode {LEGACY, SECURE, SUPER_STRICT, DISABLED};` in some of your dependency point release. Some libraries have a vast number of headers, beyond what a human can review. The API is compatible, but you just silently introduced a severe security regression in any package not rebuilt. Thankfully, this is a tooling issue and `libabigail` exists for C/C++. So most distribution have the means to track what needs to be rebuilt if they integrate those tools. Template code makes the problem worse, but it not solely a C++ problem.

I am not familiar with the tooling Rust has to track ABI breakages, but I assume it could be handled using tooling rather than try to maintain a stable shared library ABI across versions.

Shared libraries

Posted Nov 25, 2025 2:46 UTC (Tue) by khim (subscriber, #9252) [Link] (2 responses)

> I assume it could be handled using tooling rather than try to maintain a stable shared library ABI across versions.

Not really. One example: let's convert your enum SecurityMode {LEGACY, SECURE, DISABLED}; to Rust and add Option<…&rt; wrapping. And now look on how different versions of Rust thread that. Nice, isn't it? The same effect that you just described—but without any source changes, just with different compiler. And no, release notes wouldn't save you, either, there are nothing in them about this change.

> I am not familiar with the tooling Rust has to track ABI breakages

Easy: it doesn't exist. cargo_semver_checks is very through, but it only tracks source compatibility. Never binary. Stable ABI doesn't exist, period.

There was some interest in development of such ABI, but effort have stalled.

Shared libraries

Posted Nov 25, 2025 9:12 UTC (Tue) by taladar (subscriber, #68407) [Link] (1 responses)

Considering the number of edge cases the cargo-semver-checks author constantly documents on his blog even at the API level I doubt an approach that would satisfy Rust's high standard for correctness will ever exist at the ABI level.

It mostly works in C and C++ since those seem to have much lower standards for what they consider 'working'.

Shared libraries

Posted Nov 25, 2025 13:49 UTC (Tue) by khim (subscriber, #9252) [Link]

With Swift approach (roughly: make dyn Trait as capable as impl Trait at the cost of implementation speed) there would be no material difference between ABI stability checks and API stability checks.

Sure, it would be a bit work to provide stable ABI and most crates wouldn't bother, but if someone want to create a “Rust platform” (similarly to how iOS and macOS are “Swift platforms”) then it's perfectly doable if costly.

Shared libraries

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

> There is a reason why most distros rebuild binaries when the dependencies change.

The claim that this is not sustainable for Debian also seems strange, given that a lot of distros do manage to do it (including non-commercial ones like NixOS).

Shared libraries

Posted Nov 25, 2025 15:02 UTC (Tue) by intelfx (subscriber, #130118) [Link] (1 responses)

> The claim that this is not sustainable for Debian also seems strange, given that a lot of distros do manage to do it (including non-commercial ones like NixOS).

> given that a lot of distros do manage to do it (including non-commercial ones like NixOS).

NixOS is only managing to do it because commercial sponsors dump relatively huge money into operation of their CI and binary cache.

Same also goes for other "non-commercial" distros — if you look closer, you'll find they all have commercial sponsors subsidizing the infrastructure.

Shared libraries

Posted Nov 25, 2025 18:49 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Gentoo also exists, btw. And it doesn't appear to have many corporate sponsors.