<div dir="ltr">Nico brought up this topic and made me think whether the current choice of --build-id was the right one or not.<div><br></div><div>Currently, we compute a FNV1 hash for an entire resulting file and store it to .note.gnu.build-id section. It's one of the slowest parts of the linker because reading every byte takes time. IIRC, it usually takes about 10% of total link time.</div><div><br></div><div>In the first place, I believe it was not a good decision to make GCC (and therefore Clang) to pass --build-id option to the linker by default (<a href="https://lists.debian.org/debian-gcc/2009/07/msg00082.html">it was done in 2009</a>). Build ID is sometimes useful, particularly when distributing linked objects to users, but in most cases it is not needed. Spending 10% more time on usual build-link-debug cycle is a waste of time. It should not have been added that casually.</div><div><br></div><div>Anyways, the option is there and passed to the linker, so we have to create and add a build ID if --build-id option is given (we could ignore the option but that's probably very confusing.)</div><div><br></div><div>So here's my proposal.</div><div><br></div><div> - Make --build-id=uuid as default for --build-id</div><div><br></div><div>--build-id=uuid sets build-id to a random unique value. It's very fast. Instead, it breaks build reproducibility because every build has a unique build ID. But if you want build reproducibility, you can explicitly pass --build-id=sha1.</div></div>