On Mon, Jan 12, 2026 at 11:36:26PM +0100, Guillem Jover wrote: > Hi! > > On Mon, 2026-01-12 at 23:29:00 +0100, Guillem Jover wrote: > > diff --git i/man/dpkg-buildflags.pod w/man/dpkg-buildflags.pod > > index 7a759eb7a..9f1fc3d6c 100644 > > --- i/man/dpkg-buildflags.pod > > +++ w/man/dpkg-buildflags.pod > > @@ -322,11 +322,15 @@ Since dpkg 1.17.7. > > =item B<LDFLAGS> > > > > Options passed to the host compiler when linking executables or shared > > -objects (if the linker is called directly, then > > -B<-Wl> > > -and > > -B<,> > > -have to be stripped from these options). > > +objects. > > + > > +If the linker is called directly > > +(a discouraged practice in the common case, > > +unless necessary for low level projects), > > +then only the B<-o>, B<--output>, B<-l>, B<-L>, B<-f>, B<-Wl> options and > > +their arguments should be passed over, > > +with B<-Wl> getting stripped and B<,> in its arguments replaced with > > spaces. > > + > > Default value: empty. > > > > =item B<ASFLAGS_FOR_BUILD> > > Sorry, I think -f should probably be omitted from there (as I think at > least GNU ld ignores those options anyway?),
On amd64 the FTBFS in question is with -fcf-protection. > otherwise it should be > made conditional to being passed only when -shared is passed, but that > starts to be too much detail for my taste. Sometimes changing documentation what each affected package has to do manually sounds like the worst possible option to me. Either dpkg provides a LDFLAGS_FOR_LD that simply works for this case, or the best option might be to document not using dpkg LDFLAGS at all when ld gets called directly. > Thanks, > Guillem cu Adrian
