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.am...@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@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.am...@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@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 <tha...@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.am...@apple.com> wrote: > >>> > >>> > >>> On Nov 21, 2016, at 2:44 PM, Nico Weber <tha...@chromium.org> wrote: > >>> > >>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini <mehdi.am...@apple.com> > >>> wrote: > >>>> > >>>> > >>>> On Nov 21, 2016, at 2:27 PM, Nico Weber <tha...@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. > >>> > >>> > >>> 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@lists.llvm.org > >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > >> > >> > >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
