Bug#1125715: diet-ng: FTBFS on arm64: Unable to detect linker for compiler `ldc2 -L=--version /tmp/tmpp57y3ut8.d -L=-z -L=relro -mbranch-protection=standard -release -wi -g -O2`

Hello Guillem and Simon,

On 2026-01-16 08:51, Guillem Jover wrote:
> On Fri, 2026-01-16 at 17:58:40 +0100, Emanuele Rocca wrote:
> > It seems that dpkg-buildflags erroneously started adding to LDFLAGS
> > -mbranch-protection=standard, while that is not a linker argument.
> 
> Hmm, according to #1115292 (commit cdf5f5da0e0cb6f9f4d51e93fd9583bd578c252f)
> this is needed to avoid warnings from the compiler. Was that analysis
> wrong somehow?

I think the analysis was incorrect, yes. The -mbranch-protection flag is
for the compiler only.

Consider the following example.

First we compile two C files with -mbranch-protection=standard and check
that all the required properties are set on the object files:

$ cc -mbranch-protection=standard -c one.c
$ readelf -n one.o | grep Prop
      Properties: AArch64 feature: BTI, PAC, GCS

$ cc -mbranch-protection=standard -c two.c
$ readelf -n two.o | grep Prop
      Properties: AArch64 feature: BTI, PAC, GCS

Then we use the compiler to link the two object files, *without* passing
any branch-protection flags. The linker checks for the properties in the
object files, finds out that both are annotated, and turns on
PAC/BTI/GCS in the resulting executable too.

$ cc one.o two.o -o program
$ readelf -n program | grep Prop
      Properties: AArch64 feature: BTI, PAC, GCS

It may be that packages such as db5.3 are not using CFLAGS *when
compiling*, but the solution is most probably not adding
-mbranch-protection to LDFLAGS. That's a bit like adding -O3 to LDFLAGS
because some programs do not get optimized code.

Thanks,
  ema