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

Adhemerval Zanella Netto adhemerval.zanella@linaro.org
Tue May 5 12:27:47 GMT 2026



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:

$ 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]



More information about the Libc-alpha mailing list