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