On 2/27/26 17:01, Mark Millard wrote:
On 2/27/26 13:24, John Baldwin wrote:
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.
Likely more food for thought than you were originally trying to deal
with for aarch64 contexts. I was not trying to indicate that any
devel/freebsd-gcc* commit vs. lang/gcc* commit would/should be the same
commit. More like . . .
Are all of the potentially involved linking issues/techniques limited to
that aarch64 system context and the use of devel/freebsd-gcc* ? Or are
there, for example, "uses libcalls for outlined atomics" issues also for
lang/gcc* g++* use, especially when it is told to use -stdlib=libc++
( the system libc++ ) instead of using libstdc++ ? Do any issues and
techniques generalize beyond devel/freebsd-gcc* use in any meaningful way?
Even without committing anything for lang/gcc* , notes might prove
useful later for someone, depending on the answers to the above.
In the case of googletest and the LLVM libraries, the undefined symbols for
atomics weren't in libc++, so I think you would have the same problem if you
used lang/gccX to build googletest or llvm in ports using USE_GCC=yes or the
like on aarch64.
You also might have the problem on RISC-V for builtins where clang tends
to inline operations more often than GCC which tends to invoke libcalls.
Note that the GCC behavior is not specific to aarch64. In g++specs.cc it
defaults to passing --shared-libgcc to the backend on all platforms that
support the option unless an explicit --static-libgcc is specified on the
command line to g++. For C, it only passes --shared-gcc by default if an
ObjC object file is specified as an input to the linker.
--
John Baldwin
