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