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