<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jun 1, 2016 at 4:57 PM, Joerg Sonnenberger via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@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"><span class="">On Wed, Jun 01, 2016 at 03:21:08PM -0700, Rui Ueyama via llvm-dev wrote:<br>
> In the first place, I believe it was not a good decision to make GCC (and<br>
> therefore Clang) to pass --build-id option to the linker by default (it was<br>
</span>> done in 2009 <<a href="https://lists.debian.org/debian-gcc/2009/07/msg00082.html" rel="noreferrer" target="_blank">https://lists.debian.org/debian-gcc/2009/07/msg00082.html</a>>).<br>
<span class="">> Build ID is sometimes useful, particularly when distributing linked objects<br>
> to users, but in most cases it is not needed. Spending 10% more time on<br>
> usual build-link-debug cycle is a waste of time. It should not have been<br>
> added that casually.<br>
<br>
</span>I fully agree on this (not passing it down by default automatically),<br>
since it doesn't create a very useful key.<br>
<span class=""><br>
> --build-id=uuid sets build-id to a random unique value. It's very fast.<br>
> Instead, it breaks build reproducibility because every build has a unique<br>
> build ID. But if you want build reproducibility, you can explicitly pass<br>
> --build-id=sha1.<br>
<br>
</span>I think this is worse than not doing anything at all. What about the<br>
hash tree options, those can at least be computed piecewise and<br>
concurrently?<br></blockquote><div><br></div><div>We could but it only mitigate the issue. If the decision was wrong in the first place, I want to fix it completely if it's not too late. </div></div></div></div>