[EdiX]

> I don't get it. A linker's task should be straightforward.

In Go the linker also generates DWARF, does deadcode elimination and a bunch of other stuff described in the associated document.

> And how can it be that a binary called "cmd/compile" has 170k symbols (that's like, global definitions, right?). Not that that's a huge number in terms of today's computing power, but how many millions of lines of source code does that correspond to?

As described in the link each global function actually ends up producing 4 symbols.

> Shouldn't 1 or 2 secs be sufficient?

On my system linking cmd/compile takes 1.3 seconds. The problem is that object files get cached so if you have a hot cache (let's say you made a few changes inside a single package and then recompile) compiling takes almost no time and linking accounts for nearly 100% of the build time.

[account42]

One nice speed improvement for linking C++ (and I imagine C as well) with GCC and Clang is -gsplit-dwarf which does not link debug information but instead only references the original object files.

This of course only makes sense for development where the object files are still available for GDB to load the debug symbols from but it is a nice feature.

The MSVC linker has /DEBUG:FASTLINK as well.