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? -- === Mark Millard marklmi at yahoo.com
