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 <guil...@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 <e...@debian.org> > > wrote: > > > Source: systemd > > > Version: 257.7-1 > > > User: debian-...@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.
