<div dir="ltr">I haven't though hard enough about that, but if I were a developer writing IDE or something and wanted to use LLD, I would use it as a separate process. It's not a matter of API usability but to protect the main program from possible bugs of the library. It's like the latest browser spawns a new process for each tab.</div>

<div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Aug 2, 2013 at 2:13 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> This really should return an error_code.  When lld is a library inside an app like an IDE, we don’t want to kill the whole app because of a malformed object file.<br>


<br>
</div>No opinion about this particular error, but do we really want to use<br>
lld like that? As far as I can tell clang is not used like that. IDEs<br>
(and all build systems really) just for exec clang. Given that there<br>
are a lot more compile jobs than link jobs (and the clang driver forks<br>
to run clang -cc1), it is not clear that the savings for not doing a<br>
fork+exec for the linker would be noticeable.<br>
<br>
Second, <a href="http://llvm.org/docs/CodingStandards.html#assert-liberally" target="_blank">http://llvm.org/docs/CodingStandards.html#assert-liberally</a> has<br>
been in effect since forever, so even if all of lld and lib/Object are<br>
"perfect", the IDE would still have to fork+exec when doing LTO, since<br>
it seems almost impossible to change all of the middle end passes and<br>
code generators to avoid assert, llvm_unreachable and<br>
report_fatal_error.<br>
<br>
> -Nick<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>