[PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

Tue Nov 22 08:41:19 PST 2016

This has been like that forever, this is not new with 3.9.
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).

— 
Mehdi

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