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

On 1 Nov 2025, at 21:47, Mark Millard <marklmi@yahoo.com> wrote:
> 
> On Nov 1, 2025, at 13:17, Dimitry Andric <dim@FreeBSD.org> wrote:
...
>> 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

Yes, I found that too, and an informative blog post by Fangrui Song at <https://maskray.me/blog/2023-10-31-dso-undef-and-non-exported-definition>.

But it doesn't explain why this error only occurs for some people and not others. If I understand the llvm commit and the blog post correctly, I would expect this error to always appear. :)

-Dimitry