Re: git: 51e8e8b0f369 - main - Merge commit e24f90190c77 from llvm git (by Brad Smith):

From: Dimitry Andric <dim_at_FreeBSD.org>
Date: Sat, 01 Nov 2025 20:17:39 UTC
On 1 Nov 2025, at 20:48, Mark Millard <marklmi@yahoo.com> wrote:
> 
> Dimitry Andric <dim_at_FreeBSD.org> wrote on
> Date: Sat, 01 Nov 2025 18:40:54 UTC :
> 
>> On 31 Oct 2025, at 17:20, Jose Luis Duran <jlduran@FreeBSD.org> wrote:
>>> 
>>> On Fri, Oct 31, 2025 at 12:48 PM Dimitry Andric <dim@freebsd.org> wrote:
>>>> 
>>>> On 31 Oct 2025, at 14:48, Jose Luis Duran <jlduran@FreeBSD.org> wrote:
>>>>> 
>>>>> On Wed, Oct 29, 2025 at 3:50 PM Dimitry Andric <dim@freebsd.org> wrote:
>>>>>> 
>>>>>> . . .
>>>>> 
>>>>> I'm sure you're probably aware by now, but aarch64 builds are failing
>>>>> after this commit:
>>>>> 
>>>>> https://ci.freebsd.org/job/FreeBSD-main-aarch64-build/33100/
>>>> 
>>>> It's weird, but I cannot reproduce it. For me, both world and kernel build fine.
>>>> 
>>>> Does anybody have any particular settings that can be used to reproduce this on a fresh 16-CURRENT or 15-STABLE box?
>>> 
>>> I can reproduce it on an aarch64 VM (using a mac studio), vanilla settings:
>>> 
>>> make cleanuniverse <--- very important!
>>> make -j $(nproc) buildworld ... as usual
>> 
>> Unfortunately it still does not reproduce for me. I have tried this on two different systems. The current hypothesis is that it is due to a race in the build system.
>> 
>> At the point where the error occurs, libgcc.a (an alias of libcompiler_rt.a) should already have been built, with the __aarch64_* symbols in it. In the logs from ci.freebsd.org <http://ci.freebsd.org/> you can see that libcompiler_rt.a has already been built, and installed into ${WORLDTMP}. So it's still a mystery why this error even occurs.
> 
> When I look at the official CI log file I see, for example:
> 
> --- outline_atomic_cas4_2.o ---
> cc -target aarch64-unknown-freebsd16.0 . . . -fpic -fvisibility=hidden -DVISIBILITY_HIDDEN . . .  -c outline_atomic_cas4_2.S -o outline_atomic_cas4_2.o
> 
> Would that tend to imply that the later:
> 
> ld: error: non-exported symbol '__aarch64_cas4_acq' in '/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/libgcc.a(outline_atomic_cas4_2.o)' is referenced by DSO '/usr/obj/usr/src/arm64.aarch64/tmp/usr/lib/libgcc_s.so'
> 
> would be expected?

No, the symbol should be there, and it shouldn't be "non-exported". However, looking with readelf, I see:

Symbol table '.symtab' contains 13 entries:
   Num:    Value          Size Type    Bind   Vis       Ndx Name
...
    11: 0000000000000000     0 NOTYPE  GLOBAL HIDDEN    UND __aarch64_have_lse_atomics
    12: 0000000000000000    48 FUNC    GLOBAL HIDDEN      2 __aarch64_cas4_acq

So the symbol is global but hidden, which is because lib/libcompiler_rt/Makefile compiles everything with -fvisibility=hidden.

It has been doing that for a long time, so I am unsure why ld now suddenly makes a problem out of it. Maybe the CI builds use another linker, either on purpose or by accident?

-Dimitry