The entire post is really indicative of widespread misunderstandings on how linking is supposed to fit into the larger ecosystem. Dynamic linking — on Linux —

The entire post is really indicative of widespread misunderstandings on how linking is supposed to fit into the larger ecosystem. Dynamic linking — on Linux — isn't intended to work on its own. There's a system around it, notably with a package manager and its dependency handling. It's only a component of the larger system, and it's failing because other pieces are just straight-up missing. No, you can't build on one OS platform, transfer the executable to another, and expect it to work. Yes, other systems (notably Windows, but also Solaris and to some degree the BSDs) make that guarantee, but Linux doesn't. That's just how it is, and it's different across systems, and you need to drop that expectation. For comparison, on OpenBSD you can't link statically (not across OpenBSD versions at least) because syscalls are not an ABI. You need the system's libc, matching the kernel. (cf. recent Go story) Platforms have their own rules. Learn them. The package manager is also what will fix some of the not-quite-linking-related problems the post cites. Headers and #defines matching the library version — you get that from the package manager's build dependencies. It'll also apply compiler & linker flags that match the platform. But the most disingenious part of the article is this: > If you want to move a binary from one machine (where it was compiled) to another No. You're not moving a binary from one machine to another. You're moving it from one platform to another. Because if the machines have the same platform, it actually works.