On Thu, Jan 15, 2026 at 01:20:26PM +0100, Guillem Jover wrote:
> Hi!
Hi Guillem!
>...
> Having slept over it, I think upstream use of LDFLAGS for direct ld
> calls is just unsafe, as the general expectation is that this is to
> be used via the compiler, so IMO any such instance in upstream should
> be fixed anyway, at which point those upstreams will accept getting
> LDFLAGS (and filtering that themselves) or a direct ld(1) variable
> which we can pre-populate.
>...
"in any such instance" is not true.
"via the compiler" only makes sense when the package is actually using
a compiler.
A package like e3 that uses just nasm+ld is not using a compiler.
And when "the compiler" is called for linking, you cannot assume that it
accepts all gcc options.
The D ecosystem (e.g. glib-d) does currently FTBFS on arm64, due to dpkg
now passing -mbranch-protection=standard which is not supported by ldc.[1]
dpkg DFLAGS are documented to be used when ldc is the compiler.
> Thanks,
> Guillem
cu
Adrian
[1] ldc does support many gcc options (e.g. --fcf-protection),
but it does not (yet?) have support for this one.
