<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits <span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">mehdi_amini added a comment.<br>
<span class=""><br>
In <a href="https://reviews.llvm.org/D25932#601842" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25932#601842</a>, @rnk wrote:<br>
<br>
> In <a href="https://reviews.llvm.org/D25932#601820" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25932#601820</a>, @mehdi_amini wrote:<br>
><br>
> > 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.<br>
> ><br>
> > 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).<br>
><br>
><br>
> 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.<br>
<br>
<br>
</span>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".<br>
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.<br></blockquote><div><br></div><div>Where those archives system libraries, or other things?</div><div><br>Maybe clang could sniff archives for bitcode and pass only -flto in that case?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
><br>
><br>
>> 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.<br>
><br>
> 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?<br>
<br>
</span>No there is no such flag, what you suggest seems to work:<br>
<br>
  $ clang -flto main.c -Wl,-lto_library,/dev/null<br>
  ld: could not process llvm bitcode object file, because /dev/null could not be loaded file '/var/folders/4z/<wbr>k9mg8rls7wsfm6t6hbm0_<wbr>bxw0000gn/T/main-8e28a4.o' for architecture x86_64<br>
  clang: error: linker command failed with exit code 1 (use -v to see invocation)<br>
<br>
Also with an non-existing path:<br>
<br>
  $ clang -flto main.c -Wl,-lto_library,imaginary_<wbr>path<br>
  ld: could not process llvm bitcode object file, because imaginary_path could not be loaded file '/var/folders/4z/<wbr>k9mg8rls7wsfm6t6hbm0_<wbr>bxw0000gn/T/main-319618.o' for architecture x86_64<br>
  clang: error: linker command failed with exit code 1 (use -v to see invocation)<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
Repository:<br>
  rL LLVM<br>
<br>
<a href="https://reviews.llvm.org/D25932" rel="noreferrer" target="_blank">https://reviews.llvm.org/<wbr>D25932</a><br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
cfe-commits mailing list<br>
<a href="mailto:cfe-commits@lists.llvm.org">cfe-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-commits</a><br>
</div></div></blockquote></div><br></div></div>