Comment by dzaima
5 days ago
It's certainly not impossible to write code that breaks, or modify a library in an ABI-incompatible way, but ABI stability, at least on Linux, does largely Just Work™. A missing older shared library can be quite problematic, but that's largely it.
And while, yes, there are times where ABIs are broken, compiler versions affecting things would add a whole another uncontrollable axis on top of that. I would quite like to avoid a world of "this library can only be used by code compiled with clang-25" as much as possible.
Works most of the time, probably, isn't really the meaning of stable.
Can't solve the issue of "you just don't have the library (or a specific version thereof) installed".
But you can make it worse by changing "You must have version X of library Y installed" to "You must have version X of library Y compiled by compiler Z installed".
As-is, one can reasonably achieve ABI stability for their C library if they want to; really all it takes is "don't modify exposed types or signatures of exposed functions" and "don't use intmax_t", and currently you can actually break the latter.
You forgot about binaries compiled with incompatible build or linker flags.
There is a reason why commercial software has several combinations on their SDKs, for their libraries.
Release, debug, multi-threaded, with math emulation, with fast math, specific CPU ISA with and without SIMD, and these are only the most common ones.
3 replies →