<p dir="ltr">In what way is this chromium specific? It's "all non-xcode uses of clang on mac", no?</p>
<div class="gmail_extra"><br><div class="gmail_quote">On Nov 21, 2016 7:29 PM, "Mehdi Amini" <<a href="mailto:mehdi.amini@apple.com">mehdi.amini@apple.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><div>On Nov 21, 2016, at 2:44 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:</div><br class="m_1320269973906345199Apple-interchange-newline"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 21, 2016 at 5:34 PM, Mehdi Amini<span class="m_1320269973906345199Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:mehdi.amini@apple.com" target="_blank">mehdi.amini@apple.com</a>></span><span class="m_1320269973906345199Apple-converted-space"> </span><wbr>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class="m_1320269973906345199gmail-"><blockquote type="cite"><div>On Nov 21, 2016, at 2:27 PM, Nico Weber <<a href="mailto:thakis@chromium.org" target="_blank">thakis@chromium.org</a>> wrote:</div><br class="m_1320269973906345199gmail-m_6200437630110443680Apple-interchange-newline"><div><div dir="ltr" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote">On Mon, Nov 21, 2016 at 5:19 PM, Mehdi AMINI via cfe-commits<span class="m_1320269973906345199gmail-m_6200437630110443680Apple-converted-space"> </span><span dir="ltr"><<a href="mailto:cfe-commits@lists.llvm.org" target="_blank">cfe-commits@lists<wbr>.llvm.org</a>></span><span class="m_1320269973906345199gmail-m_6200437630110443680Apple-converted-space"> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">mehdi_amini added a comment.<br><span><br>In<span class="m_1320269973906345199gmail-m_6200437630110443680Apple-converted-space"> </span><a href="https://reviews.llvm.org/D25932#601842" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2<wbr>5932#601842</a>, @rnk wrote:<br><br>> In<span class="m_1320269973906345199gmail-m_6200437630110443680Apple-converted-space"> </span><a href="https://reviews.llvm.org/D25932#601820" rel="noreferrer" target="_blank">https://reviews.llvm.org/D2<wbr>5932#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></div></div></div></blockquote><div><br></div></span><div>We have two cases:</div><div><br></div><div>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.</div><div>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.</div></div></div></blockquote><div><br></div><div>It sounds like this is a pure regression for us then.</div></div></div></div></div></blockquote><div><br></div><div>Right, for you "downstream consumer of clang in chromium”.</div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> 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?</div></div></div></div></div></blockquote><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Requiring everyone to put a dummy libLTO.dylib at ../lib/libLTO.dylib (while clever) seems pretty unfortunate.</div></div></div></div></div></blockquote><div><br></div><div>Is there a CMake invocation that disable libLTO today and allow to run “make install” and produce a distribution of clang without libLTO?</div><div><br></div><div>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).</div><div><br></div><div>— </div><div>Mehdi</div><div><br></div><div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"></div></div></div></blockquote></div><br><blockquote type="cite"><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><span class="m_1320269973906345199gmail-"><br><blockquote type="cite"><div><div dir="ltr" style="font-family:helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><div class="gmail_quote"><div>Maybe clang could sniff archives for bitcode and pass only -flto in that case?</div></div></div></div></div></blockquote><div><br></div></span><div>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`).</div><div><br></div><div>— </div><span class="m_1320269973906345199gmail-HOEnZb"><font color="#888888"><div>Mehdi</div></font></span></div></div></blockquote></div></div></div></div></blockquote></div><br></div></blockquote></div></div>