Re: git: ee73475119ff - main - llvm: Link private LLVM libraries against compiler_rt for aarch64

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 <jhb@FreeBSD.org> wrote:
>>>>>
>>>>> The branch main has been updated by jhb:
>>>>>
>>>>> URL: https://cgit.FreeBSD.org/src/commit/?
>>>>> id=ee73475119ff7aa98bd11828625d524f6ab87f06
>>>>>
>>>>> commit ee73475119ff7aa98bd11828625d524f6ab87f06
>>>>> Author:     John Baldwin <jhb@FreeBSD.org>
>>>>> AuthorDate: 2026-02-09 16:26:52 +0000
>>>>> Commit:     John Baldwin <jhb@FreeBSD.org>
>>>>> 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