<div dir="ltr">Hi Mehdi,<div><br></div><div>We use the libLTO C API for our linker and binutils here at Sony.</div><div><br></div><div>Cheers,</div><div><br></div><div>Dave</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 3, 2016 at 6:59 PM, Mehdi Amini via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Kevin,<br>
<span class=""><br>
> On Oct 3, 2016, at 10:49 AM, Kevin Enderby <<a href="mailto:enderby@apple.com">enderby@apple.com</a>> wrote:<br>
><br>
> Hello Mehdi,<br>
><br>
> Sorry for the delayed reply I was out on vacation for that last few days.<br>
><br>
> As Pete Cooper already commented, the Apple cctools project (aka the “binutils” stuff), make use of the libLTO C API.<br>
><br>
> At this time do you want to know an exact list of each API in use?  It is not clear from your email below exactly what you are after at this point in time other than to identify who are the stakeholders.  On that I do care about the libLTO C API so we don’t break the uses in the Apple cctools project.<br>
<br>
</span>I’d like to establish a windows of deprecation of APIs.<br>
I assume that Apple’s binutils and ld64 have the same constraint/use-cases (but maybe I’m missing something).<br>
<br>
Right now I’m more interested to collect the non-Apple (non-DT) users and their constraints ;-)<br>
<br>
Thanks,<br>
<br>
—<br>
<span class="HOEnZb"><font color="#888888">Mehdi<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
><br>
>> On Sep 30, 2016, at 1:18 PM, Mehdi Amini via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
>><br>
>> Hi all,<br>
>><br>
>> libLTO is exposing a very “stable” (in the sense of immutable) C API to be used by linkers (and binutils tools) that manipulate bitcode (like when performing LTO).<br>
>><br>
>> I’m looking into relaxing the stability concern and design a policy for this API that would allow to deprecate and remove some the APIs exposed here. The MacOS linker (ld64) is one the users of libLTO, but there are others (Sony? Qualcomm? Anyone else?) that I think are also targeting this API.<br>
>><br>
>> I’d like to identify stakeholders so that we can establish a new policy that would accomodate everyone as much as possible. So if you care about the libLTO C API, please speak-up!<br>
>><br>
>> Thanks,<br>
>><br>
>> —<br>
>> Mehdi<br>
>><br>
>> ______________________________<wbr>_________________<br>
>> LLVM Developers mailing list<br>
>> <a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
><br>
<br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>