<div dir="ltr">After some discussion on IRC, we agreed to give <a href="https://reviews.llvm.org/D26984">https://reviews.llvm.org/D26984</a> a try.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 22, 2016 at 11:41 AM, Mehdi Amini <span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This has been like that forever, this is not new with 3.9.<br>
Note also that the system ar/ranlib are sensitive to the environment DYLD_LIBRARY_PATH and will look for libLTO appropriately (since they aren’t invoked with clang, we haven’t been able to do any “magic” here yet).<br>
<br>
—<br>
<span class="HOEnZb"><font color="#888888">Mehdi<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
> On Nov 22, 2016, at 6:31 AM, Jack Howarth <<a href="mailto:howarth.mailing.lists@gmail.com">howarth.mailing.lists@gmail.<wbr>com</a>> wrote:<br>
><br>
> I would also note that llvm 3.9.x and 4.0svn also require use of their<br>
> own llvm-ar and llvm-ranlib for archiving under -flto as well (beyond<br>
> using the matching libLTO.dylib).<br>
><br>
> On Tue, Nov 22, 2016 at 12:59 AM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
>> Double-checked on the latest binary release on <a href="http://llvm.org" rel="noreferrer" target="_blank">llvm.org</a>, it ships with<br>
>> clang+llvm-3.9.0-x86_64-apple-<wbr>darwin/lib/libLTO.dylib<br>
>><br>
>> I also can’t find any CMake option that disable LTO support at build time<br>
>> for clang.<br>
>><br>
>><br>
>> On Nov 21, 2016, at 9:53 PM, Mehdi Amini via cfe-commits<br>
>> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> AFAIK any clang build open-source ships with libLTO.<br>
>> Not having libLTO built with clang is a Chromium oddity, unless I missed the<br>
>> obvious somewhere.<br>
>><br>
>><br>
>> On Nov 21, 2016, at 9:50 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
>><br>
>> In what way is this chromium specific? It's "all non-xcode uses of clang on<br>
>> mac", no?<br>
>><br>
>><br>
>> On Nov 21, 2016 7:29 PM, "Mehdi Amini" <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br>
>>><br>
>>><br>
>>> On Nov 21, 2016, at 2:44 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
>>><br>
>>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>><br>
>>> wrote:<br>
>>>><br>
>>>><br>
>>>> On Nov 21, 2016, at 2:27 PM, Nico Weber <<a href="mailto:thakis@chromium.org">thakis@chromium.org</a>> wrote:<br>
>>>><br>
>>>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits<br>
>>>> <<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a>> wrote:<br>
>>>>><br>
>>>>> mehdi_amini added a comment.<br>
>>>>><br>
>>>>> In <a href="https://reviews.llvm.org/D25932#601842" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25932#601842</a>, @rnk wrote:<br>
>>>>><br>
>>>>>> In <a href="https://reviews.llvm.org/D25932#601820" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25932#601820</a>, @mehdi_amini wrote:<br>
>>>>>><br>
>>>>>>> We ship `clang + libLTO + ld64` bundled in the toolchain, so even if<br>
>>>>>>> you don't package libLTO yourself, it is already accessible from the linker:<br>
>>>>>>> it will use the one in the toolchain when needed.<br>
>>>>>>><br>
>>>>>>> I don't have an immediate idea to prevent this and have the linker<br>
>>>>>>> issue an error (other than removing manually libLTO from the Xcode<br>
>>>>>>> installation).<br>
>>>>>><br>
>>>>>><br>
>>>>>> So, even if clang doesn't pass -lto_library to ld64, ld64 will<br>
>>>>>> auto-discover the bundled libLTO that happens to be next to it? That could<br>
>>>>>> go badly.<br>
>>>>><br>
>>>>><br>
>>>>> Right: until LLVM 3.8, clang was *never* passing the `-lto_library`<br>
>>>>> option. The only way to have your own libLTO used by ld64 instead of the one<br>
>>>>> in the Xcode toolchain was setting the environment variable<br>
>>>>> "DYLD_LIBRARY_PATH".<br>
>>>>> Of course was has many issues, and that's what lead us to have clang<br>
>>>>> passing this option to ld64. Initially only when the driver was invoked with<br>
>>>>> -flto, but recently I had issues with clients that didn't use LTO themselves<br>
>>>>> but were having static archives they depend on that were containing bitcode.<br>
>>>><br>
>>>><br>
>>>> Where those archives system libraries, or other things?<br>
>>>><br>
>>>><br>
>>>> We have two cases:<br>
>>>><br>
>>>> 1) Internal teams producing libraries in an internal SDK with LTO<br>
>>>> enabled, and other teams consuming these libraries and linking to the<br>
>>>> framework. It seems also something that people out-in-the-wild are doing<br>
>>>> according to some bug reports.<br>
>>>> 2) Any Xcode user that have a somehow complex project which is split in<br>
>>>> multiple targets. Xcode can’t tell clang from one target that it is linking<br>
>>>> with LTO even if LTO is disabled just because another dependency has LTO<br>
>>>> enabled. And sometimes Xcode is only seeing static archive as an input<br>
>>>> anyway.<br>
>>><br>
>>><br>
>>> It sounds like this is a pure regression for us then.<br>
>>><br>
>>><br>
>>> Right, for you "downstream consumer of clang in chromium”.<br>
>>><br>
>>> Since 'it never "hurt" to pass it' isn't true (every link invocation done<br>
>>> by the driver now prints a warning), maybe this should be reverted until<br>
>>> there's some better approach?<br>
>>><br>
>>> Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib<br>
>>> (while clever) seems pretty unfortunate.<br>
>>><br>
>>><br>
>>> Is there a CMake invocation that disable libLTO today and allow to run<br>
>>> “make install” and produce a distribution of clang without libLTO?<br>
>>><br>
>>> If not, then I’m against reverting this because I consider your Chromium<br>
>>> specific incorrect with respect to the support upstream. And I’m fine having<br>
>>> it supported in the future, but you should make it supported, for instance<br>
>>> with a cmake option (if the cmake option already exists, I haven’t checked,<br>
>>> then we could conditionally compile-out the warning based on it).<br>
>>><br>
>>> —<br>
>>> Mehdi<br>
>>><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>>><br>
>>>><br>
>>>> Maybe clang could sniff archives for bitcode and pass only -flto in that<br>
>>>> case?<br>
>>>><br>
>>>><br>
>>>> That seems like a possibility. It’d have to resolve paths to the static<br>
>>>> archives, which it doesn’t do right now I believe (they can be resolved with<br>
>>>> `-Lpath -lfoo`).<br>
>>>><br>
>>>> —<br>
>>>> Mehdi<br>
>>><br>
>>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> cfe-commits mailing list<br>
>> <a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
>> <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
>><br>
>><br>
<br>
</div></div></blockquote></div><br></div>