<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Oct 13, 2016 at 11:48 AM, Sebastian Pop <span dir="ltr"><<a href="mailto:sebpop@gmail.com" target="_blank">sebpop@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">sebpop added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D24991#565861" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D24991#565861</a>, @EricWF wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D24991#565715" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D24991#565715</a>, @mclow.lists wrote:<br>
><br>
> > How does this play with existing binaries?  Applications that expect these functions to exist in the dylib?<br>
><br>
><br>
> This patch is majorly ABI breaking, although we could probably find a formulation that wasn't.<br>
<br>
<br>
</span>Eric, Marshall,<br>
any suggestions on how to fix the backwards compatibility issue?<br><br></blockquote><div><br></div><div>The routine *has* to be in the dylib.</div><div>That being said, that doesn't mean that the version in the dylib must be called.</div><div><br></div><div>I have an idea; it involves a macro that is sometimes "inline" and sometimes not, and changes when you're building the library vs. when you're just including the headers.</div><div><br></div><div>I'll play with that and put something up here.</div><div><br></div><div>-- Marshall</div><div> </div></div><br></div></div>