Hi Dima, Le 09/11/2025 06:59, Dima Kogan a écrit : [...]
Which results from this diff:*** work/features/load.base.3 Sun Nov 9 05:36:02 2025 --- work/features/load.log.3 Sun Nov 9 05:36:02 2025 *************** *** 1,2 **** --- 1,4 ---- rebuilding testload.so+ /lib/aarch64-linux-gnu/libc.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. + /lib/ld-linux-aarch64.so.1: 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.pre= post=testload.so implicit
Ah, it's probably some interaction between buildflags in the tests; either that or glibc hasn't been built with GCS, but then I'd expect this to show up in other packages too.
This GCS thing is described here: https://wiki.debian.org/ToolChain/GCS I haven't looked into how to enable GCS in whatever it's complaining about (might be very hard). I also haven't looked into making the expected and received warnings match (might be medium hard). The GCS page above suggests a way to silence the warning, and that does work. Adding this to debian/rules makes the package build on arm64: export DEB_LDFLAGS_MAINT_APPEND := -Wl,-z,gcs-report-dynamic=none Probably needs an if statement to do nothing on non-arm64 arches. Is this a good-enough solution, or do we want to match the warnings and/or fix gcs?
It seems good enough for now, I'll try to upload a fixed package in the next few days.
Regards, Stephen
