Open cherrymui opened 1 year ago
I agree we should have a clang+lld builder. My question is whether we should also keep a builder with the existing configuration (is it clang+bfd or clang+gold?).
I'm going to guess that we should probably have builders for every popular C linker (or whatever we're willing to say we explicitly support).
Logistical question: what can this builder share with other builders? Could it, for example, share ./make.bash
output?
Now we build the toolchain without cgo, right? If so, the result of make.bash
does not depend on the C linker at all. So we can share it.
Even if it still uses cgo, we probably can share. We just don't use LLD to link some tool binaries (the go command, the pprof command?), and that is probably fine, and we'll probably have the same coverage when linking test binaries.
We could have a builder for clang+bfd, if the builder resource is fine. I think that is probably also a popular configuration that users use.
For the record (this was mentioned in the linked issue, but worth repeating here) this exact combination would be very welcome for those of us who compile C/C++ files using zig cc
, as Zig is actually clang+lld behind the scenes.
CC @golang/release.
The LLD linker is widely used by users. Occasionally there are some subtle differences in behavior between the C linkers (BFD, Gold, LLD), that cause issues for us (e.g. we may have assumptions based on the BFD linker's specific behavior (e.g. #59466), or we may uncover a bug in the C linker itself.)
As far as I can tell, we don't have much LLD coverage on the builders. I think it is probably good to have one. The
linux-amd64-clang
builder already uses LLVM based C compiler. So it may be a good fit. (gcc+lld is possible but probably not a popular configuration.)Thoughts? Thanks.
cc @prattmic (was chatting with Michael about this the other day)