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 >> <mailto: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 >> <mailto:mehdi.am...@apple.com>> wrote: >> >>> On Nov 21, 2016, at 2:44 PM, Nico Weber <tha...@chromium.org >>> <mailto:tha...@chromium.org>> wrote: >>> >>> On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini <mehdi.am...@apple.com >>> <mailto:mehdi.am...@apple.com>> wrote: >>> >>>> On Nov 21, 2016, at 2:27 PM, Nico Weber <tha...@chromium.org >>>> <mailto:tha...@chromium.org>> wrote: >>>> >>>> On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits >>>> <cfe-commits@lists.llvm.org <mailto:cfe-commits@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). >> >> — >> 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
