Thats only true if you do not depend on glibc, which some statically compiled binaries still do. And even then, you’d have to rule out anything that requires newer sysalls or platforms that don’t offer stable ABI guarantees (Linux is actually the edge case here in that most kernels offer no guarantees).
It’s certainly doable though.
> platforms that don’t offer stable ABI guarantees
If we're talking about Windows, the Win32 ABI is considered stable, which would also suffice for what I'm looking for, which are portable binaries that can be run on almost any version of a system.
So it has C++ and so needs a C++ stdlib. Dynamically linking is annoying so what if we statically link it? Oh but GNU's C++ stdlib wants glibc and has versioned BS and so even statically linking the C++ bits isn't ideal. And as mentioned statically linking glibc is a big no no.
So:
a) build a musl and install it in a prefix
b) add a few bits (some headers and C runtime objects) and turn it into a sysroot
c) build llvm's libc++ libunwind and a couple others, linking against that sysroot, and install it in the sysroot
d) build our shared lib, statically linking against that sysroot
The result is a shared lib that is self-contained except for the C stdlib, and any reference to the C stdlib has no GNUism nor glibc version. The trick is that musl is essentially a subset of glibc + there is no such thing as a musl-ism per musl's design tenets + the C ABI is stable enough. I don't recall us statically linking to musl - IIRC the trick is just to not have any GNUism at any level, in a way it also working in musl is kind of a happy side effect - but maybe I'm wrong.
As a consequence it works on all glibc versions and musl as well, and is entirely independent of the system's preferred C++ stdlib.
A requirement though is to load the shared library with RTLD_LOCAL (to not accidentally make internal symbols available to the outside) and RTLD_DEEPBIND (to not accidentally pick external symbols instead of internal ones)
Cosmopolitan is an extreme outlier because it deliberately replaces the need for glibc. Your typical C or C++ program isn’t going to do that.
> If we're talking about Windows, the Win32 ABI is considered stable,
We are talking about most Unixes. macOS, OpenBSD, etc.
Have a look at the nightmare recipes for libc. On the other hand they do provide the basics of how to ship a custom libc loader across heterogeneous machines but it gets complicated fast and not something any non specialist can do in an hour.
In my experience anybody saying to compile statically does not know about the libc limitations. When they find them they hand wave, I smile and say be my guest.
By the way 2.17 is an appropriate version to target. RHEL6 much? :D
We used https://crosstool-ng.github.io/docs/ to create a cross-compilation toolchain that runs on modern debian, but produces executables that only need glibc 2.17. The only downside is that you no longer can simply apt-get a library you need -- all dependencies shipped along with your application also need to be built with this cross-compiler.
God, I hate glibc so much. It’s an absolutely terrible design from the 80s. It can and should be trivial to target any arbitrary version of glibc. The way Linux performs linking is so bad and so much worse than Windows. (Headers + thin import lib. Linking expecting a full and complete so is stupid and bad.)
Zig solved this problem. It can trivially target any version of glibc and cross-compile. It’d be nice if the Linux community demanded this level of functionality from their toolchains. Alas. https://andrewkelley.me/post/zig-cc-powerful-drop-in-replace...
What Zig does is goes way way way out of it's way to compile import libs which contains all of the exported functions but the implementations are empty.
So you aren't wrong. But the point is that the monumentally large Linux ecosystem does not work that way. Which is a real shame.
Of course, new code may actually need features from newer libc, and often you won't be able to frankenstein your way out of it with no-op plug functions and copypasting successfully.
There's also a random page on the internet with a barebones cross-distribution compatibility guide:
https://gist.github.com/wagenet/35adca1a032cec2999d47b6c40aa...
In general, “community support” shrinks to “ride on what Red Hat provides”.
The actual dependency is 2.14, when a faster memcpy was added, 2.17 is just whatever I happened to have around back when I compiled my stuff, I just didn't change anything since then, bits don't rot.
Most operating systems don’t provide guarantees about ABI stability between versions, instead mandating that libc (or other user space APIs) are the intended interface to syscalls.
Because if this, you can often come across statically compiled executables will still depend on glibc while inlining stuff like libpng.
> if you depend on glibc... things can still break, e.g. when compiled on too new glibc it fails to run on older versions.
That’s the point I was making ;)