[llvm-dev] lld: ELF/COFF main() interface

[David Chisnall via llvm-dev]

On 22 Jan 2016, at 12:08, Rafael Espíndola via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> It is not. Having to fight back your push and mischaracterization of the situation has cost a lot of time, sleep and productivity. In particular, it is certainly not true when you say:
> 
> ------------------
> During the discussion, there was a *specific* discussion of both the new COFF port and ELF port continuing to be libraries with a common command line driver
> --------------
> 
> Rui's design was explicit enough that this was going to be just a linker to get me excited about it. If you didn't pick it up you were simply not paying attention.
> 
> I have been tracking llvm since 2007 and I can't remember another situation as bad as this. Had the project been like this      I would probably have found something else to do.
> 
> In the future if you have something you want but existing developers don't care about (lld should make coffee), remember the burden is on you to show that it will not interfere with the rest. It is not OK to push people saying their work should not be part of llvm if they don't do what you want.

I completely agree.  LLVM has needed a linker for a long time.  Various efforts have edged in that direction for *years*.  The current LLD is actually getting the work done and I’m looking forward to being able to replace the ageing BFD ld as the FreeBSD base system linker.

I would love to have a set of libraries implementing linker functionality for use in other projects.  It would be great if MCJIT could reuse the linker code just as it reuses the back-end code.  It would be great if clang could multithreaded compilation with in-process incremental linking.  But a prerequisite for all of this is some working code that implements linker functionality.

LLVM has a long history of large-scale refactorings of the code, but you can’t refactor code that doesn’t exist and we should be afraid of the idea that some of the lld code will need to be refactored.  Even proper error handling is something that can be added later.  If LLVM had a policy of stable library interfaces across releases, then I would argue differently, but given that out of tree users of the LLVM libraries need to do significant rewrites of their code every six months, delaying the one concrete example of a consumer of the linker libraries that has people actively working on it so that hypothetical ones don’t that might exist in the future don’t need to modify their hypothetical code is counterproductive.

Please can we stop distracting the folks actually writing the linker?  

David