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 <mknyszek@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Run-TryBot: Michael Knyszek <mknyszek@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Cherry Mui <cherryyz@google.com>
This commit is contained in:
Michael Anthony Knyszek 2024-12-02 19:10:37 +00:00 committed by Gopher Robot
parent bdedc5c1d7
commit 4daf7922f3
1 changed files with 7 additions and 0 deletions

View File

@ -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