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.

Related: #59666

CC @golang/release.

Hello, I'm sorry for the sudden interruption.
I noticed that the gold linker may have been deprecated, see GNU Binutils 2.44 Released
.
I think it's necessary to introduce the lld linker for testing, so that we can find out if there's any behavior that depends on a particular linker. ( I found #69466 )
I noticed that under linux/arm64, the gold linker is used by default for the dynlinking scenario. Maybe this will need to be replaced with other linkers in the future.
https://github.com/golang/go/blob/master/src/cmd/link/internal/ld/lib.go#L1680
Thank you!

I think it is a good idea to test lld (that's why I filed the issue).

In the Go linker, we probably can switch off from defaulting to gold.