[PATCH] Link static C++ tests against libatomic.a if needed

[H.J. Lu]

On Tue, May 5, 2026 at 10:33 PM Jonathan Wakely <jwakely@redhat.com> wrote:
>
> On Tue, 5 May 2026 at 13:27, Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
> >
> >
> >
> > On 04/05/26 22:50, H.J. Lu wrote:
> > > On Tue, May 5, 2026 at 9:42 AM Sam James <sam@gentoo.org> wrote:
> > >>
> > >> "H.J. Lu" <hjl.tools@gmail.com> writes:
> > >>
> > >>> On Mon, May 4, 2026 at 10:33 AM H.J. Lu <hjl.tools@gmail.com> wrote:
> > >>>>
> > >>>> Define cxx-static-link-libatomic to -latomic if DT_NEEDED entries in
> > >>>> libstdc++.so include libatomic.so.  Update link-extra-libs-static to
> > >>>> include $(cxx-static-link-libatomic) if -lstdc++ is used.
> > >>>>
> > >>>> Tested with sparcv8-linux-gnu-leon3 and sparcv9-linux-gnu using
> > >>>> uild-many-glibcs.py.  This fixes BZ #34121.
> > >>>>
> > >>>
> > >>> FWIW, sparc g++ does pass -latomic_asneeded to ld.  But glibc tests
> > >>> are built with -nostdlib -nostartfiles using gcc, not g++.
> > >>
> > >> https://inbox.sourceware.org/gcc-patches/CACb0b4m+ex47Tpyp1qvW9+0p4onyEvsfXeXE_4zZrteMO5q5EQ@mail.gmail.com/
> > >>
> > >> I don't remember what happened with that, there were a few issues with
> > >> the libatomic autolinking so I lost track.
> > >
> > > One way to fix the gcc is to create libstdc++.a as linker script, similar to
> > >
> > > [hjl@gnu-tgl-3 x86-glibc]$ cat /usr/lib64/libm.a
> > > /* GNU ld script
> > > */
> > > OUTPUT_FORMAT(elf64-x86-64)
> > > GROUP ( /usr/lib64/libm-2.43.a /usr/lib64/libmvec.a )
> > > [hjl@gnu-tgl-3 x86-glibc]$
> > >
> > > to include libatomic.a in libstdc++.a if needed.  But I don't know if it works
> > > everywhere.
> > >
> >
> > It seems gcc-16 has another issue, it also fails on building glibc after a bootstrap
> > with build-many-glibcs.py with:
> >
> > [..]sparc64-glibc-linux-gnu-gcc -m32 -mlong-double-128 -mcpu=v9 -o /home/azanella/Projects/glibc/build/sparcv9-linux-gnu-gcc16/support/links-dso-program -pie  -Wl,-O1 -nostdlib -nostartfiles [...]
> > [...]/sparc64-linux-gnu/sparc64-glibc-linux-gnu/bin/ld: [...]/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/16.1.1/../../../../sparc64-glibc-linux-gnu/lib/../lib/libstdc++.so: undefined reference to `__atomic_fetch_add_4@LIBATOMIC_1.0'
> > [...]/sparc64-linux-gnu/sparc64-glibc-linux-gnu/bin/ld: [...]/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/16.1.1/../../../../sparc64-glibc-linux-gnu/lib/../lib/libstdc++.so: undefined reference to `__atomic_fetch_sub_4@LIBATOMIC_1.0'
> >
> > And dumping the linker invocation, it shows another issue:
> >
> > ld: warning: libatomic.so.1, needed by [...]/sparc64-linux-gnu/bin/../lib/gcc/sparc64-glibc-linux-gnu/16.1.1/../../../../sparc64-glibc-linux-gnu/lib/../lib/libstdc++.so, not found (try using -rpath or -rpath-link)
> >
> > It seems now that libstdc++.so is dynamic linker against libatomic.so:
> >
> > $ readelf -d ./sparc64-glibc-linux-gnu/lib/libstdc++.so | grep NEEDED
> >  0x00000001 (NEEDED)                     Shared library: [libm.so.6]
> >  0x00000001 (NEEDED)                     Shared library: [libatomic.so.1]
> >  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> >  0x00000001 (NEEDED)                     Shared library: [ld-linux.so.2]
> >  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
> >
> > Where previously (gcc-15) it seems to be statically linked:
>
> No, I don't think that's true. I don't think it was linked against
> libatomic *at all* in GCC 15.
>
> > $ readelf -d ./sparc64-glibc-linux-gnu/lib/libstdc++.so | grep NEEDED
> >  0x00000001 (NEEDED)                     Shared library: [libm.so.6]
> >  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
> >  0x00000001 (NEEDED)                     Shared library: [ld-linux.so.2]
> >  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
>
> I don't know why sparcv9 requires external calls to
> __atomic_fetch_sub_4 at all, shouldn't those be expanded to assembly
> instructions by the compiler? That's what I meant about a libstdc++
> bug in the gcc thread that Sam linked to. I'm surprised to see that
> this target has any dependency on libatomic for 4-byte atomics.
>

It is a libstdc++ bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125197

-- 
H.J.