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? Maybe clang could sniff archives for bitcode and pass only -flto in that case? > > > > > > >> This is the motivation behind the warning I believe: we're trying to > prevent this situation where a user would have clang but not his own libLTO > and may encounter an unexpected issue. Even when the user does not opt-in > to build his own project with LTO enabled, there can be static archive > dependencies that contain bitcode. > > > > I guess ld64 doesn't expose a flag like `-fno-lto` to disable this > completely? Maybe we could pass `-lto_library /dev/null` or something? > > No there is no such flag, what you suggest seems to work: > > $ clang -flto main.c -Wl,-lto_library,/dev/null > ld: could not process llvm bitcode object file, because /dev/null could > not be loaded file > '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxw0000gn/T/main-8e28a4.o' > for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > Also with an non-existing path: > > $ clang -flto main.c -Wl,-lto_library,imaginary_path > ld: could not process llvm bitcode object file, because imaginary_path > could not be loaded file > '/var/folders/4z/k9mg8rls7wsfm6t6hbm0_bxw0000gn/T/main-319618.o' > for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see > invocation) > > > Repository: > rL LLVM > > https://reviews.llvm.org/D25932 > > > > _______________________________________________ > 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