3 ms·
> Linking was also invented because . . . This is just plain wrong. Linking was, and still is, about assembling a final executable in a format and a way that a
by junon 5y ago
> Linking was also invented because . . .
This is just plain wrong. Linking was, and still is, about assembling a final executable in a format and a way that accurately describes the data within it. For example, kernels tend to need very customized linker scripts in order to place all of the data in the correct spots.
The reason why linking can be hidden in most cases is because building an executable for a specific system is generally straightforward and well specified, needing little to no tweaking or opinions about how it's built. This is not always the case, and linking was certainly not "invented" to work around binaries with no sources...
- nine_k 5y agoTheoretically, the compiler can form a complete "statically-linked" executable, and even sidestep libc to use kernel APIs. Golang tends towards this. This may diminish if not eliminate the role of linking. The case of VM-based languages is entirely out of purview of the system linker, too.
- titzer 5y ago> Theoretically, the compiler can form a complete "statically-linked" executable, and even sidestep libc to use kernel APIs. This isn't theoretical, it's exactly how Virgil generates binaries for x86-darwin, x86-linux, and x86-64-linux. The output is just one binary and no C environment. No C libraries for anything. Instead, the Virgil compiler knows the kernel ABI for the target and library code (written in Virgil) implements a thin portable layer directly in terms of syscalls using raw pointers.
- junon 5y agoAgain, that's if the compiler is the only thing contributing object code to the final executable...