4 ms·
>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
by tester756 1y ago
>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 1y agoThe 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 1y ago> 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 1y agoYou 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 1y ago> 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 1y agoI thought it is done by ffi