Compiler: Size of generated executable file

[Walter Bright]

retard wrote:
>> The file formats are complicated. The concept of what the linker does is
>> trivial, especially when we're talking about "what consumes space in the
>> exe file".
> 
> If you take for example GNU ld from binutils, it's not that trivial. It 
> even has its own scripting language. If the object file format is 
> complicated, the linker has to support most important parts of the spec, 
> at least. ld happens to support several architectures, several operating 
> systems, several language mangling conventions, and several object file 
> formats. The architecture has pluggable components and it comes with tons 
> of switches for various kinds of tuning options. As a whole, it takes 
> couple of weeks of intensive learning to really master the tool. Of 
> course some guidance helps, but the documentation isn't very good. For 
> instance setting the entry point on architectures with no operating 
> system may bloat the executable, if you don't know what you're doing.

Name mangling conventions have nothing to do with bloat, neither do 
object file formats, byte order, etc. What a linker does *is* 
conceptually trivial - it merely concatentates the binary data in the 
object files together and writes it out.

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.

If you want to know where the size in your exe file is coming from, the 
map file will tell you - broken down by each name and its associated size.

Maybe the problem is the man page for ld, which has a truly bewildering 
quantity of obtuse options, confusing people about what a linker 
actually does.