On 1 Nov 2025, at 21:47, Mark Millard <[email protected]> wrote: > > On Nov 1, 2025, at 13:17, Dimitry Andric <[email protected]> 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
