On 2/27/26 15:55, Mark Millard wrote:
On 2/27/26 09:27, John Baldwin wrote:
On 2/9/26 11:47, John Baldwin wrote:
On 2/9/26 11:40, Jessica Clarke wrote:
On 9 Feb 2026, at 16:28, John Baldwin <[email protected]> wrote:
The branch main has been updated by jhb:
URL: https://cgit.FreeBSD.org/src/commit/?
id=ee73475119ff7aa98bd11828625d524f6ab87f06
commit ee73475119ff7aa98bd11828625d524f6ab87f06
Author: John Baldwin <[email protected]>
AuthorDate: 2026-02-09 16:26:52 +0000
Commit: John Baldwin <[email protected]>
CommitDate: 2026-02-09 16:26:52 +0000
llvm: Link private LLVM libraries against compiler_rt for aarch64
This is required for GCC which uses libcalls for outlined atomics.
This doesn’t seem right, they’re provided by libgcc.a, so why aren’t
they being pulled in? libcompiler_rt.a doesn’t even have the symbols.
My guess is that we don't link libraries against libgcc by default, only
binaries (maybe this is a GCC feature/bug vs clang)? I have another
review
open for a couple of google test libraries which similarly fail to link.
So after some more digging (along with Jessica), it seems that GCC only
uses -lgcc_s (and not -lgcc) for C++ (but not C) on both Linux and FreeBSD.
clang's FreeBSD toolchain driver is supposed to mimic GCC but doesn't, it
applies the C rules even for C++ linking, so clang is implicitly adding
both -lgcc and -lgcc_s for C++.
On Linux, libgcc.so is a linker script that includes both the dynamic
library and -lgcc which is how the static libgcc (including outline atomics
for aarch64) is effectively linked into C++ shared libraries on Linux.
(Note: libgcc.so is a linker script on seemingly all arches on Linux, not
just aarch64)
So I think we have a couple of choices here. I can patch the devel/
freebsd-gccN
ports to stop passing -shared-libgcc to cc1plus which will cause GCC to
follow
the same rules as clang on FreeBSD (passing -lgcc -as-needed -lgcc_s -
no-as-needed
instead of -lgcc_s), or we could change libgcc.so to be a linker script
to match
Linux (and then eventually fix the FreeBSD driver in clang to only pass
-lgcc_s for C++ linking) (I think Andrew already has a review to make
libgcc.so
a linker script).
I can see arguments both ways. Using a linker script seems kind of dumb
given
all the hoops GCC goes to internally to decide whether or not to link only
shared or static or both. (Esp given libgcc is in theory part of the
compiler,
so the compiler should know that libgcc_s should depend on libgcc and be
able
to encode that in the default drivers.) OTOH, the linker script
approach would
mean we would more closely align with Linux. I think Jess favors
patching GCC.
Does anyone else have any strong opinions?
Is the question limited to devel/freebsd-gcc* ? Or does it span
lang/gcc* use as well?
We don't really support building the base system with lang/gcc*
(it's why devel/freebsd-gcc* exist) as the base system builds require
various changes like kernel printf support, defaulting to libc++, etc.
--
John Baldwin
