<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Thu, Jan 7, 2016 at 5:19 PM Philip Reames <<a href="mailto:listmail@philipreames.com">listmail@philipreames.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">I don't disagree with anything Chandler said, but it's worth noting
    that we *already* have a specialized in-process linker used to MCJIT
    to resolve relocations and patch things like symbolic calls.  It'd
    be really really nice if the new linker library supported that use
    case.  <br></div></blockquote><div><br></div><div>Yep. But I also think it is reasonable to design the API to support that use case when we're actually wiring it together and making it work. I think trying to build an API that we think will support that use case without actually integrating it into LLVM's JIT is much more likely to end up with the wrong API, and has a higher chance over-engineering the API into one more complex than is necessary.</div><div><br></div><div>I think that's the concern Rui has here, which seems reasonable.</div><div><br></div><div>None of this says that once someone is actually working on doing this integration we shouldn't figure out the right API and make it happen. We should. This is another use case that makes total sense.</div><div><br></div><div>-Chandler</div></div></div>