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

Tue Nov 22 11:33:36 PST 2016

After some discussion on IRC, we agreed to give
https://reviews.llvm.org/D26984 a try.

On Tue, Nov 22, 2016 at 11:41 AM, Mehdi Amini <mehdi.amini at apple.com> wrote:

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