<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Dec 13, 2016 at 10:59 PM, Sean Silva via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">Yes. Rui has bent over backwards every time a real user has come to us and said "we need X". The historical precedent here is that LLD is open to many kinds of changes, but not on theoretical grounds.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Admittedly this leads to a somewhat conservative design for the linker w.r.t. enabling new use cases. However, having been involved directly or indirectly with LLD development over the last 4 or 5 years, the number of new use cases that have been proposed fall into a very small number of categories:</div><div class="gmail_extra"><br></div><div class="gmail_extra">- I want to have "main() in a library" for a static linker. LLD/ELF currently provides this functionality (with some unfortunate caveats w.r.t. re-entrancy and other stuff, but the core functionality is there, and LLD has catered to reasonable requests to remove or mitigate the caveats).</div></div></blockquote><div><br></div><div>My previous understanding is that LLD is a drop in replacement for every system linker - COFF, ELF, MACH-O, for every architecture that LLVM supports.</div><div><br></div><div>1. Is what I said above in the scope of the LLD project?</div><div><br></div><div>2. How close is the LLD project to reaching that state?</div><div><br></div><div>3. Is there anything preventing "main() in a library" from supporting all of these platforms and architectures?</div></div><br></div></div>