diff mbox series

Link static C++ tests against libatomic.a if needed

Message ID CAMe9rOoGodBNJo9-GS+PkyucPPjpj-L_x2n1v1cSUa5z4BNOWg@mail.gmail.com (mailing list archive)
State New
Headers
Series Link static C++ tests against libatomic.a if needed |

Checks

Context Check Description
redhat-pt-bot/TryBot-apply_patch success Patch applied to master at the time it was sent
redhat-pt-bot/TryBot-32bit success Build for i686

Commit Message

H.J. Lu May 4, 2026, 2:33 a.m. UTC 
  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.

Comments

H.J. Lu May 4, 2026, 8:27 p.m. UTC | #1 
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++.
Sam James May 5, 2026, 1:42 a.m. UTC | #2 
"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.
H.J. Lu May 5, 2026, 1:50 a.m. UTC | #3 
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.
Adhemerval Zanella May 5, 2026, 12:27 p.m. UTC | #4 
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]
H.J. Lu May 5, 2026, 12:33 p.m. UTC | #5 
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 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]
>
Adhemerval Zanella May 5, 2026, 12:36 p.m. UTC | #6 
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

> 
>> 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]
>>
> 
>
H.J. Lu May 5, 2026, 2:08 p.m. UTC | #7 
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

For some reason, my ld works:

$ ./install/compilers/sparc64-linux-gnu/bin/sparc64-glibc-linux-gnu-ld -V
GNU ld (GNU Binutils) 2.46.50.20260503
  Supported emulations:
   elf64_sparc
   elf32_sparc

Please try the enclosed patch.  If it works for you, I will change it
for both dynamic and static C++ executables.
Jonathan Wakely May 5, 2026, 2:33 p.m. UTC | #8 
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.
Adhemerval Zanella May 5, 2026, 3:02 p.m. UTC | #9 
On 05/05/26 11:33, Jonathan Wakely 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.

Yeah, that is another possibility.

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

Afaik sparcv9 does have the required instruction and gcc should expand
it correctly. Could the case where libstdc++ is dropping the CXXFLAGS
used to set -mcpu=sparcv9 and thus building for an older ISA?
Adhemerval Zanella May 5, 2026, 3:24 p.m. UTC | #10 
On 05/05/26 11:08, 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
> 
> For some reason, my ld works:
> 
> $ ./install/compilers/sparc64-linux-gnu/bin/sparc64-glibc-linux-gnu-ld -V
> GNU ld (GNU Binutils) 2.46.50.20260503
>   Supported emulations:
>    elf64_sparc
>    elf32_sparc
> 
> Please try the enclosed patch.  If it works for you, I will change it
> for both dynamic and static C++ executables.
> 

I still think the resulting libstdc++ being linked against libatomic.so is
gcc build issue due some missing flags (sparcv9 should have all required C11
atomic instruction that gcc should not be required to use libatomic).

And I think we will need to evaluate better if an ABI does require libatomic
for some reason.  One of the reason we remove sparcv8 and older was exactly 
because the ISA lacks proper atomic operations.
H.J. Lu May 5, 2026, 8:37 p.m. UTC | #11 
On Tue, May 5, 2026 at 11:24 PM Adhemerval Zanella Netto
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 05/05/26 11:08, 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
> >
> > For some reason, my ld works:
> >
> > $ ./install/compilers/sparc64-linux-gnu/bin/sparc64-glibc-linux-gnu-ld -V
> > GNU ld (GNU Binutils) 2.46.50.20260503
> >   Supported emulations:
> >    elf64_sparc
> >    elf32_sparc
> >
> > Please try the enclosed patch.  If it works for you, I will change it
> > for both dynamic and static C++ executables.
> >
>
> I still think the resulting libstdc++ being linked against libatomic.so is
> gcc build issue due some missing flags (sparcv9 should have all required C11
> atomic instruction that gcc should not be required to use libatomic).
>
> And I think we will need to evaluate better if an ABI does require libatomic
> for some reason.  One of the reason we remove sparcv8 and older was exactly
> because the ISA lacks proper atomic operations.

[hjl@gnu-zen4-1 bin]$ cat /tmp/x.cc
struct S { int i; char p[1024]; };

int
main ()
{
  struct S *p = (struct S *) __builtin_malloc (__builtin_offsetof
(struct S, p) + 64);
  p->i = 5;
  asm volatile ("" : "+r" (p) : : "memory");
  __atomic_fetch_add ((int *) p, 5, __ATOMIC_RELAXED);
  asm volatile ("" : "+r" (p) : : "memory");
  if (p->i != 10)
    __builtin_abort ();
  __builtin_free (p);
  return 0;
}
[hjl@gnu-zen4-1 bin]$ ./sparc64-glibc-linux-gnu-gcc -c -O2 -o /tmp/x.o /tmp/x.cc
[hjl@gnu-zen4-1 bin]$ readelf -sW /tmp/x.o

Symbol table '.symtab' contains 15 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS x.cc
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 .data
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 .bss
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 .text.startup
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7 .note.GNU-stack
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 .eh_frame
     8: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 .comment
     9: 0000000000000000   100 FUNC    GLOBAL DEFAULT    4 main
    10: 0000000000000002     0 REGISTER GLOBAL DEFAULT  UND
    11: 0000000000000003     0 REGISTER GLOBAL DEFAULT  UND
    12: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND malloc
    13: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND free
    14: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND abort
[hjl@gnu-zen4-1 bin]$ ./sparc64-glibc-linux-gnu-gcc -c -O2 -o /tmp/x.o
/tmp/x.cc -m32
[hjl@gnu-zen4-1 bin]$ readelf -sW /tmp/x.o

Symbol table '.symtab' contains 14 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS x.cc
     2: 00000000     0 SECTION LOCAL  DEFAULT    1 .text
     3: 00000000     0 SECTION LOCAL  DEFAULT    2 .data
     4: 00000000     0 SECTION LOCAL  DEFAULT    3 .bss
     5: 00000000     0 SECTION LOCAL  DEFAULT    4 .text.startup
     6: 00000000     0 SECTION LOCAL  DEFAULT    7 .note.GNU-stack
     7: 00000000     0 SECTION LOCAL  DEFAULT    8 .eh_frame
     8: 00000000     0 SECTION LOCAL  DEFAULT    6 .comment
     9: 00000000    88 FUNC    GLOBAL DEFAULT    4 main
    10: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND malloc
    11: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __atomic_fetch_add_4
    12: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND free
    13: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND abort
[hjl@gnu-zen4-1 bin]$

-m32 defaults to

-mptr32 -mno-stack-bias -mlong-double-64 -mcpu=cypress

Does  -mcpu=cypress support __atomic_fetch_add_4?
H.J. Lu May 5, 2026, 8:44 p.m. UTC | #12 
On Wed, May 6, 2026 at 4:37 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Tue, May 5, 2026 at 11:24 PM Adhemerval Zanella Netto
> <adhemerval.zanella@linaro.org> wrote:
> >
> >
> >
> > On 05/05/26 11:08, 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
> > >
> > > For some reason, my ld works:
> > >
> > > $ ./install/compilers/sparc64-linux-gnu/bin/sparc64-glibc-linux-gnu-ld -V
> > > GNU ld (GNU Binutils) 2.46.50.20260503
> > >   Supported emulations:
> > >    elf64_sparc
> > >    elf32_sparc
> > >
> > > Please try the enclosed patch.  If it works for you, I will change it
> > > for both dynamic and static C++ executables.
> > >
> >
> > I still think the resulting libstdc++ being linked against libatomic.so is
> > gcc build issue due some missing flags (sparcv9 should have all required C11
> > atomic instruction that gcc should not be required to use libatomic).
> >
> > And I think we will need to evaluate better if an ABI does require libatomic
> > for some reason.  One of the reason we remove sparcv8 and older was exactly
> > because the ISA lacks proper atomic operations.
>
> [hjl@gnu-zen4-1 bin]$ cat /tmp/x.cc
> struct S { int i; char p[1024]; };
>
> int
> main ()
> {
>   struct S *p = (struct S *) __builtin_malloc (__builtin_offsetof
> (struct S, p) + 64);
>   p->i = 5;
>   asm volatile ("" : "+r" (p) : : "memory");
>   __atomic_fetch_add ((int *) p, 5, __ATOMIC_RELAXED);
>   asm volatile ("" : "+r" (p) : : "memory");
>   if (p->i != 10)
>     __builtin_abort ();
>   __builtin_free (p);
>   return 0;
> }
> [hjl@gnu-zen4-1 bin]$ ./sparc64-glibc-linux-gnu-gcc -c -O2 -o /tmp/x.o /tmp/x.cc
> [hjl@gnu-zen4-1 bin]$ readelf -sW /tmp/x.o
>
> Symbol table '.symtab' contains 15 entries:
>    Num:    Value          Size Type    Bind   Vis      Ndx Name
>      0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
>      1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS x.cc
>      2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
>      3: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 .data
>      4: 0000000000000000     0 SECTION LOCAL  DEFAULT    3 .bss
>      5: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 .text.startup
>      6: 0000000000000000     0 SECTION LOCAL  DEFAULT    7 .note.GNU-stack
>      7: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 .eh_frame
>      8: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 .comment
>      9: 0000000000000000   100 FUNC    GLOBAL DEFAULT    4 main
>     10: 0000000000000002     0 REGISTER GLOBAL DEFAULT  UND
>     11: 0000000000000003     0 REGISTER GLOBAL DEFAULT  UND
>     12: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND malloc
>     13: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND free
>     14: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND abort
> [hjl@gnu-zen4-1 bin]$ ./sparc64-glibc-linux-gnu-gcc -c -O2 -o /tmp/x.o
> /tmp/x.cc -m32
> [hjl@gnu-zen4-1 bin]$ readelf -sW /tmp/x.o
>
> Symbol table '.symtab' contains 14 entries:
>    Num:    Value  Size Type    Bind   Vis      Ndx Name
>      0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
>      1: 00000000     0 FILE    LOCAL  DEFAULT  ABS x.cc
>      2: 00000000     0 SECTION LOCAL  DEFAULT    1 .text
>      3: 00000000     0 SECTION LOCAL  DEFAULT    2 .data
>      4: 00000000     0 SECTION LOCAL  DEFAULT    3 .bss
>      5: 00000000     0 SECTION LOCAL  DEFAULT    4 .text.startup
>      6: 00000000     0 SECTION LOCAL  DEFAULT    7 .note.GNU-stack
>      7: 00000000     0 SECTION LOCAL  DEFAULT    8 .eh_frame
>      8: 00000000     0 SECTION LOCAL  DEFAULT    6 .comment
>      9: 00000000    88 FUNC    GLOBAL DEFAULT    4 main
>     10: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND malloc
>     11: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND __atomic_fetch_add_4
>     12: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND free
>     13: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND abort
> [hjl@gnu-zen4-1 bin]$
>
> -m32 defaults to
>
> -mptr32 -mno-stack-bias -mlong-double-64 -mcpu=cypress
>
> Does  -mcpu=cypress support __atomic_fetch_add_4?
>
> --
> H.J.

Even if sparcv9-linux-gnu glibc is compiled with -m32 -mcpu=v9,
the 32-bit libstdc++ is compiled with -mcpu=cypress.


--
H.J.
H.J. Lu May 5, 2026, 8:49 p.m. UTC | #13 
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.

> >
> >> 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]
> >>
> >
> >
>
Adhemerval Zanella May 5, 2026, 8:57 p.m. UTC | #14 
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.
H.J. Lu May 5, 2026, 9:10 p.m. UTC | #15 
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?
Adhemerval Zanella May 5, 2026, 9:15 p.m. UTC | #16 
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
H.J. Lu May 5, 2026, 9:20 p.m. UTC | #17 
On Wed, May 6, 2026 at 5:10 AM H.J. Lu <hjl.tools@gmail.com> 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?

Please show the full command-line options passed to ld.  Mine

sparc64-glibc-linux-gnu-gcc -m32 -mlong-double-128 -mcpu=v9 -o
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/support/links-dso-program
-nostdlib -nostartfiles     -Wl,-z,relro
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/csu/crt1.o
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/csu/crti.o
`sparc64-glibc-linux-gnu-gcc -m32 -mlong-double-128 -mcpu=v9
--print-file-name=crtbegin.o`
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/support/links-dso-program.o
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/support/libsupport_nonshared.a
-lstdc++ -lgcc  -lgcc_s  -Wl,-dynamic-linker=/lib/ld-linux.so.2
-Wl,-rpath-link=/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/math:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/elf:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/dlfcn:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/nss:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/nis:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/rt:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/resolv:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/mathvec:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/support:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/misc:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/debug:/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/nptl:/export/build/gnu/tools-build/glibc-many/install/compilers/sparc64-linux-gnu/lib/gcc/sparc64-glibc-linux-gnu/16.1.1/../../../../sparc64-glibc-linux-gnu/lib/../lib/
-lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/libc.so.6
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/libc_nonshared.a
-Wl,--as-needed
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/elf/ld.so
-Wl,--no-as-needed -lgcc -Wl,--as-needed -lgcc_s -Wl,--no-as-needed
`sparc64-glibc-linux-gnu-gcc -m32 -mlong-double-128 -mcpu=v9
--print-file-name=crtend.o`
/export/build/gnu/tools-build/glibc-many/build/glibcs/sparcv9-linux-gnu/glibc/csu/crtn.o

works.
H.J. Lu May 5, 2026, 9:21 p.m. UTC | #18 
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. Lu May 6, 2026, 12:36 a.m. UTC | #19 
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. Lu May 6, 2026, 12:52 a.m. UTC | #20 
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

The same checkout plus my glibc patch built sparcv9-linux-gnu glibc
successfully for me on Ubuntu 24.04.4 LTS.
diff mbox series

Patch

From 540427188271de75920d4ea14b7ee306fbc96453 Mon Sep 17 00:00:00 2001
From: "H.J. Lu" <hjl.tools@gmail.com>
Date: Mon, 4 May 2026 09:51:48 +0800
Subject: [PATCH] Link static C++ tests against libatomic.a if needed

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.

Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
---
 Makeconfig   |  3 ++-
 configure    | 28 ++++++++++++++++++++++++++--
 configure.ac | 16 ++++++++++++++++
 3 files changed, 44 insertions(+), 3 deletions(-)

diff --git a/Makeconfig b/Makeconfig
index 8fe7217dd7..9bf3571863 100644
--- a/Makeconfig
+++ b/Makeconfig
@@ -662,7 +662,8 @@  endif
 
 ifndef link-extra-libs
 link-extra-libs = $(LDLIBS-$(@F))
-link-extra-libs-static = $(link-extra-libs)
+link-extra-libs-static = $(link-extra-libs) \
+  $(if $(findstring -lstdc++,$(link-extra-libs)),$(cxx-static-link-libatomic),)
 endif
 
 # The static libraries.
diff --git a/configure b/configure
index c84d283bd5..39485fc91f 100755
--- a/configure
+++ b/configure
@@ -6317,6 +6317,30 @@  fi
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_ld_gnu_indirect_function" >&5
 printf "%s\n" "$libc_cv_ld_gnu_indirect_function" >&6; }
 
+# If libstdc++.so depends on libatomic.so, $CXX -static needs libatomic.a
+# to link.
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking whether $CXX -static needs with libatomic" >&5
+printf %s "checking whether $CXX -static needs with libatomic... " >&6; }
+if test ${libc_cv_cxx_static_link_libatomic+y}
+then :
+  printf %s "(cached) " >&6
+else case e in #(
+  e) libc_cv_cxx_static_link_libatomic=
+if test -n "$CXX"; then
+  libstdcxx_so=`$CXX -print-file-name=libstdc++.so`
+  if test -n "$libstdcxx_so" \
+     && test -f "$libstdcxx_so" \
+     && $READELF -d $libstdcxx_so | grep -q libatomic.so; then
+    libc_cv_cxx_static_link_libatomic=-latomic
+  fi
+fi ;;
+esac
+fi
+{ printf "%s\n" "$as_me:${as_lineno-$LINENO}: result: $libc_cv_cxx_static_link_libatomic" >&5
+printf "%s\n" "$libc_cv_cxx_static_link_libatomic" >&6; }
+config_vars="$config_vars
+cxx-static-link-libatomic = $libc_cv_cxx_static_link_libatomic"
+
 # Check if gcc supports attribute ifunc as it is used in libc_ifunc macro.
 { printf "%s\n" "$as_me:${as_lineno-$LINENO}: checking for gcc attribute ifunc support" >&5
 printf %s "checking for gcc attribute ifunc support... " >&6; }
diff --git a/configure.ac b/configure.ac
index 280ec8e5b3..c59f02b635 100644
--- a/configure.ac
+++ b/configure.ac
@@ -780,6 +780,22 @@  if ${CC-cc} $CFLAGS $CPPFLAGS $LDFLAGS \
 fi
 rm -f conftest*])
 
+# If libstdc++.so depends on libatomic.so, $CXX -static needs libatomic.a
+# to link.
+AC_CACHE_CHECK([whether $CXX -static needs with libatomic],
+	       libc_cv_cxx_static_link_libatomic, [dnl
+libc_cv_cxx_static_link_libatomic=
+if test -n "$CXX"; then
+  libstdcxx_so=`$CXX -print-file-name=libstdc++.so`
+  if test -n "$libstdcxx_so" \
+     && test -f "$libstdcxx_so" \
+     && $READELF -d $libstdcxx_so | grep -q libatomic.so; then
+    libc_cv_cxx_static_link_libatomic=-latomic
+  fi
+fi])
+LIBC_CONFIG_VAR([cxx-static-link-libatomic],
+		[$libc_cv_cxx_static_link_libatomic])
+
 # Check if gcc supports attribute ifunc as it is used in libc_ifunc macro.
 AC_CACHE_CHECK([for gcc attribute ifunc support],
 	       libc_cv_gcc_indirect_function, [dnl
-- 
2.54.0