Shared libraries [LWN.net]

Shared libraries

Posted Nov 25, 2025 17:06 UTC (Tue) by ssokolow (guest, #94568)
In reply to: Shared libraries by farnz
Parent article: APT Rust requirement raises questions

What you're describing sounds like what they aim to produce with CrABI.

An opt-in stable ABI for Rust that serves as a higher-level alternative to what you currently get from extern "C" without having to use the abi_stable crate to marshal your types through the C ABI.

to post comments

Shared libraries

Posted Nov 25, 2025 17:18 UTC (Tue) by farnz (subscriber, #17727) [Link] (3 responses)

It's more than CrABI, but CrABI is a necessary component of it.

I want both CrABI, so that I have a compiler that can give me a stable ABI, and a way to cleanly identify which things are ABI, so that a future version of cargo-semver-checks can tell me not only that I've broken my API stability promises (leaving me to decide if I bump the major version, or if I fix my API), but also that I've broken my ABI stability promises.

I also want to be able to say that my stable ABI depends on you using a compatible stable API crate as part of the build process - just as I can't use a random header file version in C, and rely on it working with a random shared library version - that allows for things like carefully chosen inlining of part of my code into the caller, while still having chunks of my internals in my shared library (e.g. so that fast path code can be inlined, calling a slow path in my shared library).

On top of that, while I'm demanding perfect tooling, moon-onna-stick, and free unicorns for everyone, I want tooling that allows me to knowingly break ABI as long as I provide the necessary shims to let people who linked against the older ABI to continue to work.

Shared libraries

Posted Nov 25, 2025 19:16 UTC (Tue) by ssokolow (guest, #94568) [Link] (2 responses)

just as I can't use a random header file version in C, and rely on it working with a random shared library version

For varying definitions of "rely on"

https://abi-laboratory.pro/index.php?view=tracker

On top of that, while I'm demanding perfect tooling, moon-onna-stick, and free unicorns for everyone, I want tooling that allows me to knowingly break ABI as long as I provide the necessary shims to let people who linked against the older ABI to continue to work.

Knowing the Rust community, give it a decade and you'll probably have all that.

Shared libraries

Posted Nov 26, 2025 10:00 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

My definition of "rely on" is "the tooling gives me an error if I mismatch the shared library version and the header file". Very few C and C++ libraries make that guarantee - the only library I'm aware of that does make that guarantee is glibc, and they do a lot of work with symbol versioning to make that happen.

Shared libraries

Posted Nov 26, 2025 10:15 UTC (Wed) by ssokolow (guest, #94568) [Link]

I missed that you said "can't" instead of "can". Sorry.

I suspect anything which satisfies both your goals and the Rust devs' goals will be paired with some kind of link-time hackery to ensure that what would otherwise have been statically linked will refuse to start if the subset of the provided library that's being used is not 100% ABI compatible.

"'Just don't make mistakes' doesn't scale" is, after all, a core element of Rust's design philosophy.