On Nov 1, 2025, at 13:17, Dimitry Andric <[email protected]> wrote: > On 1 Nov 2025, at 20:48, Mark Millard <[email protected]> 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 <[email protected]> wrote: >>>> >>>> On Fri, Oct 31, 2025 at 12:48 PM Dimitry Andric <[email protected]> wrote: >>>>> >>>>> On 31 Oct 2025, at 14:48, Jose Luis Duran <[email protected]> wrote: >>>>>> >>>>>> On Wed, Oct 29, 2025 at 3:50 PM Dimitry Andric <[email protected]> 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
