3 ms·

The glibc dependency can usually be eliminated through the same process of static compilation; the binaries I linked are also built this way with no dependencie

The glibc dependency can usually be eliminated through the same process of static compilation; the binaries I linked are also built this way with no dependencies on glibc, for example. > 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.

rcxdude 2y ago
statically linking against glibc does break some things (it's not an officially supported option because of that), though musl is an option and for most apps a reasonable replacement.
- lloeki 2y ago
  At work we have this C++ that needs to be distributed as, in essence, a shared lib, and that needs to work with a lot of variability. 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)
hnlmorg 2y ago
> The glibc dependency can usually be eliminated through the same process of static compilation; the binaries I linked are also built this way with no dependencies on glibc, for example. 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.

rcxdude 2y ago

statically linking against glibc does break some things (it's not an officially supported option because of that), though musl is an option and for most apps a reasonable replacement.

lloeki 2y ago
At work we have this C++ that needs to be distributed as, in essence, a shared lib, and that needs to work with a lot of variability. 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)

hnlmorg 2y ago

> The glibc dependency can usually be eliminated through the same process of static compilation; the binaries I linked are also built this way with no dependencies on glibc, for example. 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.