Shared libraries
Shared libraries
Posted Nov 24, 2025 20:20 UTC (Mon) by ebee_matteo (guest, #165284)In reply to: Shared libraries by ibukanov
Parent article: APT Rust requirement raises questions
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.