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

[Nico Weber via cfe-commits]

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


>
> 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/dfdb3d55/attachment-0001.html>