6 ms·

> However, there is one big elephant in the room: right now, there are a lot of platforms that do not fully support static linking because you have to dynamical

> However, there is one big elephant in the room: right now, there are a lot of platforms that do not fully support static linking because you have to dynamically link libc or other system interfaces. The only one I know of that supports static linking is Linux. > The ironic thing is that operating systems only supported a stable syscall ABI, rather than requiring programs to dynamically link system libraries, they would have less problems with ABI breaks. > With a statically-linked binary, you can copy it to another machine with a Linux that supports all of the needed syscalls, and it will just run. I think this is a misunderstanding. With Linux there is a stable interface at the kernel boundary. Other OSes have their stable interfaces in user space. The difference is mostly irrelevant in this context. In one case you dynamically call into the kernel, in another case you dynamically link a user space library. Either way the code you're calling isn't static but the interface is.

amelius 5y ago
I'm distributing my code as a bootable USB drive.
CyberShadow 5y ago
There is a distinction between a fully-static binary and a non-fully-static one, which is what I think the article refers to. A fully static binary will not need to call the dynamic linker at all, and tools such as "file" or "ldd" will identify such binaries differently. A fully static binary will also run even in the complete absence of any userspace support for its architecture (assuming the hardware and kernel do support it) - e.g. a static AArch64 binary will run on a 32-bit ARM distribution, if the CPU supports AArch64.
- ChrisSD 5y ago
  True, however... > assuming the hardware and kernel do support it Assuming kernel support is doing a lot of heavy lifting there. To put it another way, why is a syscall better than any other stable ABI? If both kernel and stable library are distributed together then why should it be considered different?
  - garethrowlands 5y ago
    Indeed, Linux is the outlier here. Maybe it's better. But the designers of, say, Solaris, Mac and Windows didn't think so.
    - SAI_Peregrinus 5y ago
      Even Linux isn't really the outlier. The syscall convention is stable, but you're not statically linking the kernel into your binary. A "library OS" like FreeRTOS does exactly that: the kernel is just another library, with functions that you call like any other static dependency. You can only run one process (the OS & your userspace code are that process). Really the "fully static" side is only seen in practice in RTOSes and similar embedded systems work. Being able to dynamically load more than a single process is just too handy to give up entirely. I don't think the opposite extreme has even been tried (every single symbol in its own .so, even within the kernel), the overhead would be ridiculous.
  - Brian_K_White 5y ago
    If a kernel and library really are always distributed together, so religiously iron clan that you can and should treat them as a single object, then why are they not in fact a single object? A syscall may not be inherently too different from any other interface, but a single interface is certainly different from two interfaces.
  - ghoward 5y ago
    Author here. Kernel support is actually easy: since Linux hardly ever removes syscalls, just build your fully-static executable on the oldest Linux you have, and then deploy it on all of your relevant machines. The syscalls used by all of your libraries, if they work on that oldest Linux, would work on the newer ones. In fact, this is why AppImage "Best Practices" includes building on the oldest system. [1] [1]: https://docs.appimage.org/reference/best-practices.html?highlight=oldest#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html?high...
    - gnufx 5y ago
- deleted 5y ago
  [deleted]
- ghoward 5y ago
  Author here. This is exactly what I was getting at. Thank you.
PaulDavisThe1st 5y ago
The word "static" is being conflated with "stable". A "static interface" isn't a thing. There's stable and unstable interfaces, and static and dynamic linkage. Not strongly related.
AshamedCaptain 5y ago
And to assume that only the syscall ABI layer is important is quite the understatement. I have software from the 90s that would work perfectly fine if it weren't for the fact that /etc/mtab is now a symlink. And that is just an example of the most smallish change -- not going to enter into the bazillions of binaries that are broken due to changes in audio APIs (even though the syscall numbers are still the same). Static linking for future-proofing/compatibility has never been a valid argument in my experience. Not only it is much easier to fix (and debug) a broken dynamically linked binary than a statically linked one, I would even dare to say that statically linked binaries break much more frequently than dynamically linked ones when you change the rest of the system. Even when you include the breakage from libraries changing under the feet of the dynamic binaries.

amelius 5y ago

I'm distributing my code as a bootable USB drive.

CyberShadow 5y ago

There is a distinction between a fully-static binary and a non-fully-static one, which is what I think the article refers to. A fully static binary will not need to call the dynamic linker at all, and tools such as "file" or "ldd" will identify such binaries differently. A fully static binary will also run even in the complete absence of any userspace support for its architecture (assuming the hardware and kernel do support it) - e.g. a static AArch64 binary will run on a 32-bit ARM distribution, if the CPU supports AArch64.

ChrisSD 5y ago
True, however... > assuming the hardware and kernel do support it Assuming kernel support is doing a lot of heavy lifting there. To put it another way, why is a syscall better than any other stable ABI? If both kernel and stable library are distributed together then why should it be considered different?
- garethrowlands 5y ago
  Indeed, Linux is the outlier here. Maybe it's better. But the designers of, say, Solaris, Mac and Windows didn't think so.
  - SAI_Peregrinus 5y ago
    Even Linux isn't really the outlier. The syscall convention is stable, but you're not statically linking the kernel into your binary. A "library OS" like FreeRTOS does exactly that: the kernel is just another library, with functions that you call like any other static dependency. You can only run one process (the OS & your userspace code are that process). Really the "fully static" side is only seen in practice in RTOSes and similar embedded systems work. Being able to dynamically load more than a single process is just too handy to give up entirely. I don't think the opposite extreme has even been tried (every single symbol in its own .so, even within the kernel), the overhead would be ridiculous.
- Brian_K_White 5y ago
  If a kernel and library really are always distributed together, so religiously iron clan that you can and should treat them as a single object, then why are they not in fact a single object? A syscall may not be inherently too different from any other interface, but a single interface is certainly different from two interfaces.
- ghoward 5y ago
  Author here. Kernel support is actually easy: since Linux hardly ever removes syscalls, just build your fully-static executable on the oldest Linux you have, and then deploy it on all of your relevant machines. The syscalls used by all of your libraries, if they work on that oldest Linux, would work on the newer ones. In fact, this is why AppImage "Best Practices" includes building on the oldest system. [1] [1]: https://docs.appimage.org/reference/best-practices.html?highlight=oldest#binaries-compiled-on-old-enough-base-system https://docs.appimage.org/reference/best-practices.html?high...
  - gnufx 5y ago
deleted 5y ago
[deleted]
ghoward 5y ago
Author here. This is exactly what I was getting at. Thank you.

PaulDavisThe1st 5y ago

The word "static" is being conflated with "stable". A "static interface" isn't a thing. There's stable and unstable interfaces, and static and dynamic linkage. Not strongly related.

AshamedCaptain 5y ago

And to assume that only the syscall ABI layer is important is quite the understatement. I have software from the 90s that would work perfectly fine if it weren't for the fact that /etc/mtab is now a symlink. And that is just an example of the most smallish change -- not going to enter into the bazillions of binaries that are broken due to changes in audio APIs (even though the syscall numbers are still the same). Static linking for future-proofing/compatibility has never been a valid argument in my experience. Not only it is much easier to fix (and debug) a broken dynamically linked binary than a statically linked one, I would even dare to say that statically linked binaries break much more frequently than dynamically linked ones when you change the rest of the system. Even when you include the breakage from libraries changing under the feet of the dynamic binaries.