MaskRay wrote:
Thanks for putting this together. However, I don't know the case for flipping
the default holds up.
On cost. lld defaults to a BLAKE3 based fast build-id, but but it still costs
time. On GNU ld it likely costs more.
GCC parity still holds. `gcc/configure.ac` on master still has
`enable_linker_build_id=no`.
Defaults should serve whoever can't easily override. Builds that want a
build-id already have a build configuration: a spec file, `debian/rules`, a CI
job, a toolchain definition. Builds that don't want it are the inner
development loop - many relinks a day, no config file, nobody tuning them.
Shifting cost onto that group to save packagers a flag they've already set
seems backwards.
I realize the counter is that you often don't know at link time whether you'll
want the ID. But you then should explicitly specify --build-id={fast,md5,sha1}.
**More fundamentally, I think the CMake option is the wrong mechanism for
distro policy.** A distribution that wants `--build-id` by default can express
that in a clang configuration file instead of a compile-time flag. This works
cleanly since at least Clang 18. We should try harder to remove such CMake
options.
https://github.com/llvm/llvm-project/pull/212620
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
