7 ms·

The root cause of all C ABI problems are shared libraries. They give so much trouble with little to no benefits. Ideally no application should use them. All dep

The root cause of all C ABI problems are shared libraries. They give so much trouble with little to no benefits. Ideally no application should use them. All dependencies should be compiled from sources with the same compiler and standard library. System libraries aren't needed either, it should be possible to perform syscalls directly. In such approach no ABI incompatibility can happen. One may say, that shared libraries can save some space for both disk storage and RAM. But such savings aren't that huge and in some cases are even negative - if a library is linked-in, it's possible to discard unused functionality and even inline many library functions.

zbentley 1mo ago
This has been somewhat argued to death, but even if you put aside operational concerns with static linking (security/size/independent upgradability), many attempts to do away with shared library ABIs end up reinventing them--at least for software whose job it is to integrate with other software on the machine, which is a lot of it. If you statically link a cryptography stack, you suddenly need a lot more information about what certificate/cipher systems are available on the host via IPC. If you statically link media codecs, you suddenly need a lot more information about hardware acceleration from the host via IPC. If you statically link libraries to manipulate binary data in some shared format, you need extra code to runtime-determine things like endianness. If you're asking hardware to do chunky numerical math, suddenly you need to prepare data with specific widths/sizes and you need to determine that from somewhere. Windows did good work here with COM, but the average windows app is both more self-contained and targets fewer configurations than a Linux app, so many of those issues don't come up as often as they do on Linux. Linux has a long way to go here, both because there's nothing as capable/ubiquitous as COM there, and because so much Linux software is small and therefore necessarily not self-contained (not talking about the UNIX philosophy and shell tools here--talking more about runtime intermediate layers like VAAPI or compat shims or protocols with multiple implementations).

zbentley 1mo ago

This has been somewhat argued to death, but even if you put aside operational concerns with static linking (security/size/independent upgradability), many attempts to do away with shared library ABIs end up reinventing them--at least for software whose job it is to integrate with other software on the machine, which is a lot of it. If you statically link a cryptography stack, you suddenly need a lot more information about what certificate/cipher systems are available on the host via IPC. If you statically link media codecs, you suddenly need a lot more information about hardware acceleration from the host via IPC. If you statically link libraries to manipulate binary data in some shared format, you need extra code to runtime-determine things like endianness. If you're asking hardware to do chunky numerical math, suddenly you need to prepare data with specific widths/sizes and you need to determine that from somewhere. Windows did good work here with COM, but the average windows app is both more self-contained and targets fewer configurations than a Linux app, so many of those issues don't come up as often as they do on Linux. Linux has a long way to go here, both because there's nothing as capable/ubiquitous as COM there, and because so much Linux software is small and therefore necessarily not self-contained (not talking about the UNIX philosophy and shell tools here--talking more about runtime intermediate layers like VAAPI or compat shims or protocols with multiple implementations).