Shared libraries [LWN.net]

Shared libraries

Posted Nov 24, 2025 19:22 UTC (Mon) by ibukanov (subscriber, #3942)
In reply to: Shared libraries by DemiMarie
Parent article: APT Rust requirement raises questions

The big difference between C++ and Rust is that the former has stable ABI while the former lacks those. Of cause even with Rust one can expose things across shared libraries using C-ABI, but then Rust code calling such C-based API will have to use unsafe when calling those even when the implementation is fully safe. With C++ if one avoids templates one can use class-based API including support for virtual functions that can be called across shared library boundaries.

to post comments

Shared libraries

Posted Nov 24, 2025 20:20 UTC (Mon) by ojeda (subscriber, #143370) [Link]

There is no standard C++ ABI, though vendors try to help to some degree.

As for unsafe calls, that is the same as in C++, i.e. every call is unsafe.

By the way, in Rust you can easily specify nowadays that an external function is safe, e.g.

unsafe extern "C" {
    safe fn f();
}

Shared libraries

Posted Nov 24, 2025 20:20 UTC (Mon) by ebee_matteo (guest, #165284) [Link] (5 responses)

> the former has stable ABI

Except when it hasn't.

ARMv5 ABI changed after GCC 7 (we all love our -Wno-psabi).

C++11 also broke ABI in several ways. See GCC 5 and the libstdc++ versioning fiasco. `_GLIBCXX_USE_CXX11_ABI` for the win.

GCC 11 broke ABI with GCC 10 due to std::span.

jmp_buf has different ABI for s390 after glibc 2.19.

I can cite more.

Yes, C++ has slightly better ABI guarantees than Rust, but mostly just because its usage is widespread enough, across so many decades, that it came to be that way /de facto/ after people spent years fighting with ABI problems.
In fact, I am not aware of a standardised ABI for C++ at all.

And as other people have pointed out, you still have the issue of macros and templates to solve when you use the C++ headers.

C is the closest we have to a stable ABI, assuming the same macros are defined at the time of inclusion.

And you can write Rust programs exporting C mangled functions, and that works just fine also to produce shared libs. But that's the best you can do as of today.

I guess at some point the pressure will be enough for Rust to standardize something resembling an ABI, but the widespread use of monomorphization makes it extremely tricky to do. C++ already had enough of problems with the infamous "extern template" feature of C++98, and now with C++ modules. Which, years after standardization, mostly still do not work.

Shared libraries

Posted Nov 24, 2025 22:48 UTC (Mon) by randomguy3 (subscriber, #71063) [Link] (1 responses)

Just to add to the list, we had cause to discover at work that appleclang had a subtle C++ ABI break between two minor versions of its compiler (I think it was between 14.0.0 and 14.0.3).

Shared libraries

Posted Nov 24, 2025 23:06 UTC (Mon) by ballombe (subscriber, #9523) [Link]

Given Apple track record at this point, what would be noteworthy is a XCode release that does not introduce new bugs. A subtle ABI breakage is the minimum to expect.

Shared libraries

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

I guess at some point the pressure will be enough for Rust to standardize something resembling an ABI

Work already in progress: Tracking Issue for the experimental crabi ABI

extern "crabi" is intended to be a higher-level alternative to extern "C".

Shared libraries

Posted Nov 25, 2025 20:04 UTC (Tue) by khim (subscriber, #9252) [Link] (1 responses)

Is it really “in progress” if last message is more than year old?

I would say “there's a dream”, at this point, not “there's a progress”.

Shared libraries

Posted Nov 25, 2025 20:43 UTC (Tue) by ssokolow (guest, #94568) [Link]

Fair point.

Shared libraries

Posted Nov 25, 2025 17:55 UTC (Tue) by ssokolow (guest, #94568) [Link]

Of cause even with Rust one can expose things across shared libraries using C-ABI, but then Rust code calling such C-based API will have to use unsafe when calling those even when the implementation is fully safe.

I don't remember seeing unsafe use in the examples for the abi_stable crate.

It's a Rust-to-C-to-Rust binding generator for making things like .so-based systems, similar to how PyO3 will let you write code to interface Rust and Python and it'll take care of generating the unsafe bits and wrapping them up in invariant-enforcing abstractions.

There are a lot of that sort of binding helper for Rust: