Historically it was required to ask for libatomic explicitly with
-latomic, but with GCC >= 16 apps will get linked to libatomic
whether they ask for it or not.

This invalidates QEMU's check for atomic op support for int128
which explicitly does NOT want to use the libatomic impl. As a
result with GCC >= 16, QEMU is now getting linked to libatomic
and is activating CONFIG_ATOMIC128. This in turn exposes a bug
in GCC's libatomic.a static buld which is incompatible with the
use of -static-pie leading to build failures like:

    /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/16/libatomic.a(cas_16_.o): relocation R_X86_64_32 against hidden symbol `libat_compare_exchange_16_i1' can not be used when making a PIE object
    /usr/bin/ld: failed to set dynamic section sizes: bad value
collect2: error: ld returned 1 exit status

The newly introduced -fno-link-libatomic flag can be used to
disable the new automatic linking of libatomic. Setting this in
qemu_isa_flags early on ensures that the check for CONFIG_ATOMIC128
still works correctly.

Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
---
 meson.build | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/meson.build b/meson.build
index db87358d62..56df08c10e 100644
--- a/meson.build
+++ b/meson.build
@@ -445,6 +445,15 @@ if host_arch in ['i386', 'x86_64']
   endif
 endif
 
+# GCC >= 16 automatically tries to link libatomic for all programs.
+#
+# QEMU explicitly does NOT want to use libatomic for int128 types.
+#
+# Later checks assume we won't get atomic ops for int128 without
+# explicitly asking for -latomic, so we must disable GCC's new
+# automatic linking with the new -fno-link-libatomic flag
+qemu_isa_flags += cc.get_supported_arguments('-fno-link-libatomic')
+
 qemu_common_flags = qemu_isa_flags + qemu_common_flags
 
 if get_option('prefer_static')
-- 
2.52.0

On 1/9/26 01:14, Daniel P. Berrangé wrote:
> Historically it was required to ask for libatomic explicitly with
> -latomic, but with GCC >= 16 apps will get linked to libatomic
> whether they ask for it or not.
> 
> This invalidates QEMU's check for atomic op support for int128
> which explicitly does NOT want to use the libatomic impl. As a
> result with GCC >= 16, QEMU is now getting linked to libatomic
> and is activating CONFIG_ATOMIC128. This in turn exposes a bug
> in GCC's libatomic.a static buld which is incompatible with the
> use of -static-pie leading to build failures like:
> 
>      /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/16/libatomic.a(cas_16_.o): relocation R_X86_64_32 against hidden symbol `libat_compare_exchange_16_i1' can not be used when making a PIE object
>      /usr/bin/ld: failed to set dynamic section sizes: bad value
> collect2: error: ld returned 1 exit status
> 
> The newly introduced -fno-link-libatomic flag can be used to
> disable the new automatic linking of libatomic. Setting this in
> qemu_isa_flags early on ensures that the check for CONFIG_ATOMIC128
> still works correctly.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>

Reviewed-by: Richard Henderson <richard.henderson@linaro.org>

And queued.


r~

On 1/8/26 15:14, Daniel P. Berrangé wrote:
> Historically it was required to ask for libatomic explicitly with
> -latomic, but with GCC >= 16 apps will get linked to libatomic
> whether they ask for it or not.
> 
> This invalidates QEMU's check for atomic op support for int128
> which explicitly does NOT want to use the libatomic impl. As a
> result with GCC >= 16, QEMU is now getting linked to libatomic
> and is activating CONFIG_ATOMIC128. This in turn exposes a bug
> in GCC's libatomic.a static buld which is incompatible with the
> use of -static-pie leading to build failures like:
> 
>      /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/16/libatomic.a(cas_16_.o): relocation R_X86_64_32 against hidden symbol `libat_compare_exchange_16_i1' can not be used when making a PIE object
>      /usr/bin/ld: failed to set dynamic section sizes: bad value
> collect2: error: ld returned 1 exit status
> 
> The newly introduced -fno-link-libatomic flag can be used to
> disable the new automatic linking of libatomic. Setting this in
> qemu_isa_flags early on ensures that the check for CONFIG_ATOMIC128
> still works correctly.
> 
> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> ---
>   meson.build | 9 +++++++++
>   1 file changed, 9 insertions(+)
> 
> diff --git a/meson.build b/meson.build
> index db87358d62..56df08c10e 100644
> --- a/meson.build
> +++ b/meson.build
> @@ -445,6 +445,15 @@ if host_arch in ['i386', 'x86_64']
>     endif
>   endif
>   
> +# GCC >= 16 automatically tries to link libatomic for all programs.
> +#
> +# QEMU explicitly does NOT want to use libatomic for int128 types.
> +#
> +# Later checks assume we won't get atomic ops for int128 without
> +# explicitly asking for -latomic, so we must disable GCC's new
> +# automatic linking with the new -fno-link-libatomic flag
> +qemu_isa_flags += cc.get_supported_arguments('-fno-link-libatomic')
> +
>   qemu_common_flags = qemu_isa_flags + qemu_common_flags
>   
>   if get_option('prefer_static')

Great. :/  Is there a bug reported for the -static-pie issue?

Acked-by: Paolo Bonzini <pbonzini@redhat.com>

Paolo

On Thu, Jan 08, 2026 at 04:15:38PM +0100, Paolo Bonzini wrote:
> On 1/8/26 15:14, Daniel P. Berrangé wrote:
> > Historically it was required to ask for libatomic explicitly with
> > -latomic, but with GCC >= 16 apps will get linked to libatomic
> > whether they ask for it or not.
> > 
> > This invalidates QEMU's check for atomic op support for int128
> > which explicitly does NOT want to use the libatomic impl. As a
> > result with GCC >= 16, QEMU is now getting linked to libatomic
> > and is activating CONFIG_ATOMIC128. This in turn exposes a bug
> > in GCC's libatomic.a static buld which is incompatible with the
> > use of -static-pie leading to build failures like:
> > 
> >      /usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/16/libatomic.a(cas_16_.o): relocation R_X86_64_32 against hidden symbol `libat_compare_exchange_16_i1' can not be used when making a PIE object
> >      /usr/bin/ld: failed to set dynamic section sizes: bad value
> > collect2: error: ld returned 1 exit status
> > 
> > The newly introduced -fno-link-libatomic flag can be used to
> > disable the new automatic linking of libatomic. Setting this in
> > qemu_isa_flags early on ensures that the check for CONFIG_ATOMIC128
> > still works correctly.
> > 
> > Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
> > ---
> >   meson.build | 9 +++++++++
> >   1 file changed, 9 insertions(+)
> > 
> > diff --git a/meson.build b/meson.build
> > index db87358d62..56df08c10e 100644
> > --- a/meson.build
> > +++ b/meson.build
> > @@ -445,6 +445,15 @@ if host_arch in ['i386', 'x86_64']
> >     endif
> >   endif
> > +# GCC >= 16 automatically tries to link libatomic for all programs.
> > +#
> > +# QEMU explicitly does NOT want to use libatomic for int128 types.
> > +#
> > +# Later checks assume we won't get atomic ops for int128 without
> > +# explicitly asking for -latomic, so we must disable GCC's new
> > +# automatic linking with the new -fno-link-libatomic flag
> > +qemu_isa_flags += cc.get_supported_arguments('-fno-link-libatomic')
> > +
> >   qemu_common_flags = qemu_isa_flags + qemu_common_flags
> >   if get_option('prefer_static')
> 
> Great. :/  Is there a bug reported for the -static-pie issue?

GCC maintainers tell me that -static-pie is unsupported for anything
except libgcc.a / libstdc++.a:

  https://bugzilla.redhat.com/show_bug.cgi?id=2427891#c10


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|