> On Nov 21, 2016, at 4:29 PM, Mehdi Amini <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).
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
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
