On Mon, 13 Oct 2025 at 20:53, Joseph Myers <[email protected]> wrote:
> 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.) > I think that's a libstdc++ bug, I'll look into it.
