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
