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

[Guillem Jover]

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

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

So, to me it makes sense that the few packages that opt-in into
--fatal-warnings or -Werror or similar (which tend to be problematic
during transitions), might want to disable those to avoid unnecessary
build failures. In this particular case, I guess the alternative could be
to not patch this in those packages and let them FTBFS until all their
dependencies are rebuilt (which does not seem ideal, but shrug).

Thanks,
Guillem