Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 2:22 UTC (Tue) by Elv13 (subscriber, #106198)
In reply to: Shared libraries by hunger
Parent article: APT Rust requirement raises questions

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.

to post comments

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.