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

On Nov 1, 2025, at 13:17, Dimitry Andric <dim@FreeBSD.org> wrote:

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

May be something like:

QUOTE from https://github.com/llvm/llvm-project/issues/86777
("[lld] why does lld export hidden symbols without warning when dynamic libraries link to object files?")

swift-ci
added a commit that references this issue on Mar 29, 2024
[ELF] Enhance --no-allow-shlib-undefined for non-exported definitions
df54f62
For a DSO with all DT_NEEDED entries accounted for, if it contains an
undefined non-weak symbol that shares a name with a non-exported
definition (hidden visibility or localized by a version script), and
there is no DSO definition, we should report an error.

llvm#70769 implemented the error when we see `ref.so def-hidden.so`. This patch
implementes the error when we see `def-hidden.so ref.so`, matching GNU
ld.

Close llvm#86777
END QUOTE

(Only a guess on my part.)

===
Mark Millard
marklmi at yahoo.com