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

[Jack Howarth via cfe-commits]

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
>
>