On Fri, 10 Oct 2025, Jonathan Wakely wrote: > On Fri, 10 Oct 2025 at 21:11, Joseph Myers wrote: > > > On Fri, 10 Oct 2025, Matthew Malcomson wrote: > > > > > Questions for others: > > > 1) We'd like to double-check that this sounds like a problem before > > trying to > > > change it. > > > 2) Does this trigger thoughts of anything else to look out for? > > > 3) Would the best solution be to add some `--as-needed` push/pop state > > > arguments into the link line? > > > > Yes, I'd expect libstdc++ to be linked (DT_NEEDED) with libatomic only if > > it actually has undefined references that libatomic resolves. > > > > > We try quite hard to avoid libstdc++ having any undefined references to > libatomic functions. The atomics inside the library are defined in terms of > the config/cpu/**/atomicity.h functions, which only operate on int and > which are defined using inline assembly (and spinlocks when needed). That's > partly because those functions predate libatomic, but partly because it > makes libstdc++ self-sufficient. > > So until now, users only needed to link to libatomic if their own code used > atomics on types that require libatomic calls, but libstdc++.so doesn't do > that.
My build-many-glibcs.py bot is showing a testsuite build failure for sparcv9-linux-gnu, where static libstdc++ has an undefined reference to __atomic_fetch_add_4, resulting in failure to link nptl/tst-cancel24-static. Either it's a bug that these undefined references have appeared, or else the glibc build system needs to know about linking such static tests with -latomic as well as -lstdc++ (glibc tests necessarily use -nostdlib, so GCC knowing about linking with -latomic as needed by default doesn't help them). (The shared libstdc++ for the same target has DT_NEEDED for libatomic, but it's a static test that fails to link, static libraries not having any such way to communicate their dependencies on other libraries.) -- Joseph S. Myers [email protected]
