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

[Mehdi Amini via cfe-commits]

> On Nov 21, 2016, at 4:29 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
> 
>> 
>> On Nov 21, 2016, at 2:44 PM, Nico Weber <thakis at chromium.org <mailto:thakis at chromium.org>> wrote:
>> 
>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini <mehdi.amini at apple.com <mailto:mehdi.amini at apple.com>> wrote:
>> 
>>> On Nov 21, 2016, at 2:27 PM, Nico Weber <thakis at chromium.org <mailto: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 <mailto:cfe-commits at lists.llvm.org>> wrote:
>>> mehdi_amini added a comment.
>>> 
>>> In https://reviews.llvm.org/D25932#601842 <https://reviews.llvm.org/D25932#601842>, @rnk wrote:
>>> 
>>> > In https://reviews.llvm.org/D25932#601820 <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).

I’d also add that such a cmake configuration flag (for example `DISABLE_CLANG_LTO_SUPPORT`) should also issue an error when -flto is passed on the command line.

— 
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/20161121/efde68c3/attachment-0001.html>