4 ms·

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 nee

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
    If you build against, say, RHEL5, you presumably acquire vulnerabilities in relevant libraries, give up hardware support, and still can't guarantee it will run correctly. That's at least because Linux interfaces aren't stable in general, specifically the pseudo-filesystem ones, thinking of real examples.
deleted 5y ago
[deleted]
ghoward 5y ago
Author here. This is exactly what I was getting at. Thank you.

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
  If you build against, say, RHEL5, you presumably acquire vulnerabilities in relevant libraries, give up hardware support, and still can't guarantee it will run correctly. That's at least because Linux interfaces aren't stable in general, specifically the pseudo-filesystem ones, thinking of real examples.

deleted 5y ago

[deleted]

ghoward 5y ago

Author here. This is exactly what I was getting at. Thank you.