Hacker News Reader

Comment by CyberShadow | Hacker News Reader

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.

View on HN

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?

Indeed, Linux is the outlier here. Maybe it's better. But the designers of, say, Solaris, Mac and Windows didn't think so.

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.

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.

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?high...

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.

Author here.

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

Reply on news.ycombinator.com