Shared libraries [LWN.net]

Shared libraries

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

> 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.

to post comments

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.