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

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