retard wrote:
To me it feels like a modern linker is more a simple compiler than a 'cat' utility.

That may be true if the linker is doing JITting or some such, but Optlink and ld do nothing like that and do not do anything resembling what a compiler does.

One could argue that also the compiler is a huge concatenation system which concatenates "sections" (statements and expressions) and produces executable code for the linker.

That is not a useful mental model of what a compiler does. I'm trying to impart a mental model of what the linker does that is useful in that it makes sense of what goes in the linker and what comes out of it.


My linker of choice has a frontend for the scripting language, several translation engines to convert between object file formats, byte orders etc. It also does optimization and modifies executable code & symbol names when needed/ asked. It does kind of conditional compilation since I can pack many versions of the same code in to the executable. In addition linker can do stuff like code injection and link time evaluation (even ld can do that).

No wonder you're confused about what a linker does! Yes, some linkers do those things. No, they are NOT the prime thing that it does. The prime thing a linker does is concatenate blocks of data together and write them out.

Controlling the order of those sections, dealing with byte orders, file formats, etc., is all detail.


At its core, you could conceivably design an object format and have the
linker *actually* just concatenate those files to form an executable.
The original MS-DOS executable file format wasn't even a file format, it
was nothing more than binary data that was copied into memory and
blindly jumped to.
I've been using *nix since I learned to read. I couldn't be more interested in legacy cp/m or m$ crap.

I think early executable formats for unix (and other machines of that day) were pretty much the same. Over time, complexity got layered on, but the fundamentals never changed.


The man page only shows a basic set of switches to use the linker. In reality you need lots of other documentation just to write linker scripts or when writing operating systems or programs for embedded platforms.

You don't need to know any of that to figure out what is consuming space in your exe file.

(BTW, exe files for embedded systems tend to be nothing more than binary data to be blown into EPROMs - blindly jumped to by the microprocessor.)

Reply via email to