Hacker News new | ask | show | jobs
by immibis 334 days ago
Linking works the way it does because of inertia.

There's a pretty broad space of possible ways to link (both static and dynamic). Someone once wrote one of them, and it was good enough, so it stuck, and spread, and now everything assumes it. It's far from the only possible way, but you'd have to write new tooling to do it a different way, and that's rarely worth it. The way they selected is pretty reasonable, but not optimal for some use cases, and it may even be pathological for some.

At least Linux provides the necessary hooks to change it: your PT_INTERP doesn't have to be /lib64/ld-linux-x86-64.so.2

There are many different ways linking can work (both static and dynamic); the currently selected ways are pretty reasonable points in that space, but not the only ones, and can even be pathological in some scenarios.

Actually, a whole lot of things in computing work this way, from binary numbers, to 8-bit bytes, to filesystems, to file handles as a concept, to IP addresses and ports, to raster displays. There were many solutions to a problem, and then one was implemented, and it worked pretty well and it spread, even though other solutions were also possible, and now we can build on top of that one instead of worrying about which one to choose underneath. If you wanted to make a computer from scratch you'd have to decide whether binary is better than decimal, bi-quinary or balanced ternary... or just copy the safe, widespread option. (Contrary to popular belief, very early computers used a variety of number bases other than binary)

2 comments

Linking is not done the same way in all platforms or compiled programming languages, if anything most of the inercia has been on FOSS OSes.
Really, on which platform is a static library not a bundle of object files?
Moving goal posts, you point apparently was about linking as general OS process to make libraries, and not static libraries in particular.

So many differences, not every programming language relies on the OS linker UNIX style, many have had the linking process as part of their own toolchain, outside BSDs/Linux, other vendors have had improvements on their object file formats, linking algorithms, implementations of linking processes, delayed linking on demand.

Bytecode based OSes like Burroughs/ClearPath MCP, OS/400 (IBM i), also have their own approach how linking takes place and so forth.

Some OSes like Windows Phone 8.x used a mixed executable format with bytecode and machine symbols, with final linking step during installation on device.

Oberon used slim binaries with compressed ASTs, JIT compiled on load, or plain binaries. The linker was yet another compiler pass.

Many other examples to look into, across systems research.

Far from "Linking works the way it does because of inertia.".

Well you'd first have to invent the universe of course