[tester756]

>The hard-to-understand linker errors are typically caused by the compiler, not the linker (it's the compiler that speculatively chooses to use a symbol with a long and funny name, thinking that it'll later be provided by <somebody>, when in fact the linker later finds out that no library or object file actually provided said symbol; and then for the linker to give you a decent error message, it needs to have a pretty good understanding of what the compiler was actually trying to do - i.e. to know implementation details of the compiler that otherwise would not concern it at all).

So... maybe let's avoid having linker as another/external tool and just let compiler perform linking

[boricj]

The linker stitches object files together, regardless of their origin. If a compiler directly outputs a finalized artifact, then it would be impossible to add code written in other programming languages into the mix unless the compiler also doubles as a linker.

[tester756]

> then it would be impossible to add code written in other programming languages into

Is this really that important that we cannot skip this requirement?

[raddan]

You might be surprised how often multi-language programs appear. Basically all of modern day Python for starters. But also a number of important numerical libraries for C are actually written in Fortran.

[jay-barronville]

> You might be surprised how often multi-language programs appear. Basically all of modern day Python for starters. But also a number of important numerical libraries for C are actually written in Fortran.

In my experience, the most common use case is C-based programs with some C++ sprinkled in (especially if you need the C code to be compiled exclusively by a C compiler in order to maintain C semantics).

[tester756]

I thought it is done by ffi