XPost: linux.debian.bugs.dist 
 From: guillem@debian.org 
  
 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  
 > wrote: 
 > > Source: systemd 
 > > Version: 257.7-1 
 > > User: debian-arm@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 
  
 --- SoupGate-Win32 v1.05 
  * Origin: you cannot sedate... all the things you hate (1:229/2)