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

[Nico Weber via cfe-commits]

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
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20161122/5c282e9b/attachment.html>