4 ms·

This can work only if you own the entire codebase and have all external dependencies that you depend on statically link (compiled) within your product. I also

This can work only if you own the entire codebase and have all external dependencies that you depend on statically link (compiled) within your product. I also very much prefer this way of handling dependencies but it's not a solution for all ABI problems since it also implies that you will need to statically link (compile) against all the transient dependencies. These are including at very minimum libc++ or libstdc++. And with this requirement in place this already isn't possible for many of the codebases out there. And it also brings another issue at the table: X version of libc++/libstdc++ depends on Y version of libc. Since you generally cannot statically link against the libc, and you don't own it since it's part of the OS, this becomes a hairy problem. You really need to make sure that your code works across different versions and thereof combinations of libc++/libstdc++/libc. And then there's ... a bunch of other different platforms which aren't Linux.

JonChesterfield 2y ago
Glibc is obstructive to static linking but musl is not. That gives you a binary that relies on the Linux syscall interface and nothing else. I believe bsd's libc statically links without problems as well. Libc++ is set up for static linking out of the box (if you manage to find or guess the many cmake flags). OSX and Windows insist on libc iirc but they're closed systems anyway so controlling your dependency graph is unavailable.
- menaerus 2y ago
  The problem with musl is its malloc implementation. It is subpar when compared to glibc malloc. And we know that glibc malloc is generally subpar when compared to jemalloc. For large-scale applications with many (concurrent) (small) allocations this will be a big performance problem. I guess (?) it would be possible to fix this by replacing the musl inline malloc implementation by statically linking against the jemalloc.
  - intelVISA 2y ago
    That's a good point, haven't looked too deep as I avoid allocations but musl+jemalloc is workable in Rust at least.
  - JonChesterfield 2y ago
    Changing malloc for a different one you like more would work fine in musl. In particular because it has a sane bootstrap structure which means the dynamic loader can call normal C functions, it'll be swap out the code and carry on as normal. I'd suggest replacing it in libc itself instead of requiring a separate library though.

JonChesterfield 2y ago

Glibc is obstructive to static linking but musl is not. That gives you a binary that relies on the Linux syscall interface and nothing else. I believe bsd's libc statically links without problems as well. Libc++ is set up for static linking out of the box (if you manage to find or guess the many cmake flags). OSX and Windows insist on libc iirc but they're closed systems anyway so controlling your dependency graph is unavailable.

menaerus 2y ago
The problem with musl is its malloc implementation. It is subpar when compared to glibc malloc. And we know that glibc malloc is generally subpar when compared to jemalloc. For large-scale applications with many (concurrent) (small) allocations this will be a big performance problem. I guess (?) it would be possible to fix this by replacing the musl inline malloc implementation by statically linking against the jemalloc.
- intelVISA 2y ago
  That's a good point, haven't looked too deep as I avoid allocations but musl+jemalloc is workable in Rust at least.
- JonChesterfield 2y ago
  Changing malloc for a different one you like more would work fine in musl. In particular because it has a sane bootstrap structure which means the dynamic loader can call normal C functions, it'll be swap out the code and carry on as normal. I'd suggest replacing it in libc itself instead of requiring a separate library though.