cmd/link/internal/ld: work around FreeBSD 14.1 cmd/cgo test link failure

On FreeBSD 14.1 we fail to link against C code with internal linking.
The symptom is apparently undefined symbols, but explicitly pointing the
linker at compiler-rt for -libgcc fixes the issue. This looks a lot like
the workaround on OpenBSD, but the symptom is different.
--print-libgcc-file-name produces libclang_rt.builtins-x86_64.a which
appears to be an insufficient subset of libcompiler_rt.a.

For #61095.

Change-Id: Iff5affbc923d69c89d671a69d8f4ecaadac42177
Cq-Include-Trybots: luci.golang.try:gotip-freebsd-amd64
Reviewed-on: https://go-review.googlesource.com/c/go/+/632975
Auto-Submit: Michael Knyszek <[email protected]>
LUCI-TryBot-Result: Go LUCI <[email protected]>
Run-TryBot: Michael Knyszek <[email protected]>
TryBot-Result: Gopher Robot <[email protected]>
Reviewed-by: Cherry Mui <[email protected]>

Author: mknyszek

src/cmd/link/internal/ld/lib.go

@@ -632,6 +632,13 @@ func (ctxt *Link) loadlib() {
 			if *flagLibGCC == "" {
 				*flagLibGCC = ctxt.findLibPathCmd("--print-libgcc-file-name", "libgcc")
 			}
+			if runtime.GOOS == "freebsd" && strings.HasPrefix(filepath.Base(*flagLibGCC), "libclang_rt.builtins") {
+				// On newer versions of FreeBSD, libgcc is returned as something like
+				// /usr/lib/clang/18/lib/freebsd/libclang_rt.builtins-x86_64.a.
+				// Unfortunately this ends up missing a bunch of symbols we need from
+				// libcompiler_rt.
+				*flagLibGCC = ctxt.findLibPathCmd("--print-file-name=libcompiler_rt.a", "libcompiler_rt")
+			}
 			if runtime.GOOS == "openbsd" && *flagLibGCC == "libgcc.a" {
 				// On OpenBSD `clang --print-libgcc-file-name` returns "libgcc.a".
 				// In this case we fail to load libgcc.a and can encounter link