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

Tue May 5 21:21:55 GMT 2026

On Wed, May 6, 2026 at 5:15 AM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 05/05/26 18:10, H.J. Lu wrote:
> > On Wed, May 6, 2026 at 4:57 AM Adhemerval Zanella Netto
> > <adhemerval.zanella@linaro.org> wrote:
> >>
> >>
> >>
> >> On 05/05/26 17:49, H.J. Lu wrote:
> >>> On Tue, May 5, 2026 at 8:36 PM Adhemerval Zanella Netto
> >>> <adhemerval.zanella@linaro.org> wrote:
> >>>>
> >>>>
> >>>>
> >>>> On 05/05/26 09:33, H.J. Lu wrote:
> >>>>> On Tue, May 5, 2026 at 8:27 PM 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:
> >>>>>>
> >>>>>> [..-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-glibc-lisparc64-linux-gnunux-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)
> >>>>>
> >>>>> Which version of binutils are you using?  Binutils master branch works
> >>>>> for me for sparc64-glibc-linux-gnu.
> >>>>
> >>>> It is a pretty recent one:
> >>>>
> >>>> $ ./bin/sparc64-glibc-linux-gnu-ld -v
> >>>> GNU ld (GNU Binutils) 2.46.0.20260504
> >>>
> >>> This shouldn't happen since __atomic_fetch_sub_4 is only referenced
> >>> inside of libstdc++.so.  Why can't ld find libatomic.so.1? Mine has
> >>>
> >>> [hjl@gnu-zen4-1 lib]$ pwd
> >>> /export/build/gnu/tools-build/glibc-many/install/compilers/sparc64-linux-gnu/sparc64-glibc-linux-gnu/lib
> >>> [hjl@gnu-zen4-1 lib]$ ls
> >>> ldscripts              libgomp.la        libstdc++exp.a
> >>> libatomic.a            libgomp.so        libstdc++exp.la
> >>> libatomic_asneeded.a   libgomp.so.1      libstdc++fs.a
> >>> libatomic_asneeded.so  libgomp.so.1.0.0  libstdc++fs.la
> >>> libatomic.la           libgomp.spec      libstdc++.la
> >>> libatomic.so           libitm.a          libstdc++.modules.json
> >>> libatomic.so.1         libitm.la         libstdc++.so
> >>> libatomic.so.1.2.0     libitm.so         libstdc++.so.6
> >>> libgcc_s_asneeded.so   libitm.so.1       libstdc++.so.6.0.35
> >>> libgcc_s.so            libitm.so.1.0.0   libstdc++.so.6.0.35-gdb.py
> >>> libgcc_s.so.1          libitm.spec       libsupc++.a
> >>> libgomp.a              libstdc++.a       libsupc++.la
> >>> [hjl@gnu-zen4-1 lib]$ file libatomic.so.1.2.0
> >>> libatomic.so.1.2.0: ELF 32-bit MSB shared object, SPARC32PLUS, V8+
> >>> Required, total store ordering, version 1 (SYSV), dynamically linked,
> >>> with debug_info, not stripped
> >>> [hjl@gnu-zen4-1 lib]$
> >>>
> >>> Something seems wrong in your setup.
> >> I built the sparc64 toolchain using build-many-glibcs.py and vanilla branches:
> >>
> >> * binutils: origin/binutils-2_46-branch (7db5c37036f2ddbf0db6199df6342f7945575623)
> >> * gcc:      origin/releases/gcc-16 (3ddd3407b1d0a0f49a606ea95d5dd190dd6e2d31)
> >> * glibc:    origin/release/2.43/master (e9517114acc77c0b8af9da6700107df16882b701)
> >>
> >> No extra patch applied.
> >
> > What OS does your machine run?
> >
> >
>
> It is a default x86_64 Ubuntu 24:
>
> $ uname -s -r -m
> Linux 6.8.0-111-generic x86_64

Your GCC may pass different linker options to ld.  Please
compare yours against mine in my previous email.

-- 
H.J.