Bug#1110461: systemd: FTBFS on arm64 with GCC-15 due to GCS warning

[Luca Boccassi]

Control: reassign -1 binutils
Control: retitle -1 binutils: disable gcs-report-dynamic warnings on
arm64 until all libraries are rebuilt

On Tue, 12 Aug 2025 at 17:33, Guillem Jover <guillem at debian.org> wrote:
>
> Control: reassign -1 systemd
> Control: retitle -1 systemd: FTBFS on arm64 with GCC-15 due to GCS warning
>
> Hi,
>
> On Sun, 2025-08-10 at 12:00:04 +0100, Luca Boccassi wrote:
> > Control: reassign -1 dpkg-dev 1.22.21
> > Control: reassign 1110462 dpkg-dev 1.22.21
> > Control: forcemerge -1 1110462
> > Control: retitle -1 dpkg-buildflags: add -Wl,-z,gcs-report-dynamic=none to default arm64 ldflags
>
> > On Tue, 5 Aug 2025 21:13:46 +0200 Emanuele Rocca <ema at debian.org>
> > wrote:
> > > Source: systemd
> > > Version: 257.7-1
> > > User: debian-arm at lists.debian.org
> > > Usertags: gcs
>
> > > systemd fails to build from source on arm64 if built with GCC-15,
> > currently in
> > > experimental.
> > >
> > > GCC-15 includes support for an arm64 security feature called Guarded
> > Control
> > > Stack (GCS). To help with GCS adoption, the linker warns about shared
> > libraries
> > > built without GCS. For example:
> > >
> > >  /usr/lib/gcc/aarch64-linux-gnu/15/../../../aarch64-linux-
> > gnu/libncursesw.so.6: warning: GCS is required by -z gcs, but this
> > shared library lacks the necessary property note. The dynamic loader
> > might not enable GCS or refuse to load the program unless all the
> > shared library dependencies have the GCS marking.
> > >
> > > The warning is harmless, and can be ignored. However, systemd is
> > built with
> > > --fatal-warnings, and for this reason will fail to build on arm64
> > once GCC-15
> > > becomes the default compiler in Debian.
> > >
> > > Luckily, it is possible to switch the warning off by passing the
> > argument
> > > gcs-report-dynamic=none to the linker. Please consider adding the
> > following to
> > > your debian/rules:
> > >
> > > ifeq ($(DEB_TARGET_ARCH),arm64)
> > > DEB_LDFLAGS_MAINT_APPEND=-Wl,-z,gcs-report-dynamic=none
> > > endif
> > >
> > > This can be done even before GCC-15 becomes the default compiler, to
> > avoid
> > > build failures when it does.
>
> I've been pondering about this for a bit, since the reports got
> reassigned. And today I was checking whether there was any way to
> forcibly turn specific linker warnings turned fatal errors, back
> into warnings, like it can be done with -Wno-error=foo, but that does
> not seem to be possible when using --fatal-warnings (AFAICS from
> checking the binutils source code).
>
> > Sorry but this approach does not make a lot of sense to me. It's either
> > one of:
> >
> > - all libraries need to be rebuilt with such flags, and then these bugs
> > need to be filed against the libraries mentioned in the errors above
>
> I assume a mass rebuild will be triggered when the time comes, so no
> mass bug filing seems necessary or desirable for that (as I'd assume
> it would involve pretty much all arch:any packages in the archive).
>
> > or
> >
> > - this is completely superfluous and should be ignored everywhere,
> > which means that ldflag needs to be added to the default dpkg-
> > buildflags, to avoid having to repeat the exact same workaround across
> > (some subset of) ~35k arm64 packages
>
> I'd not really feel comfortable with silencing the warning from
> dpkg-buildflags, because that would mean not even third-party builds
> will be aware that they might need to rebuild stuff. If these warnings
> were superfluous, then I think the correct place to silence/disable
> them would be in binutils (but I doubt these would have been added if
> they were superfluous).

Ok, reassigning to binutils

> I also don't think it's very common to enable --fatal-warnings in
> builds for the same reasons using -Werror is discouraged for release
> builds. Checking on codesearch.debian.net, I see only 169 source packages
> matching on that flag, which does not mean these packages enable them by
> default (only that they know about it or reference it).

This is a bit too simplistic of a search pattern, as there are many
many ways to have warnings-as-errors. Also, it is a good engineering
practice to do so, to avoid real warnings creeping in, and having your
build look like this:

https://buildd.debian.org/status/fetch.php?pkg=policykit-1&arch=amd64&ver=126-2&stamp=1737149990&raw=0

Good luck finding out whether there's a legitimate new issue with that
kind of signal-to-noise ratio.