Hi Guillem, hi Adrian, Adrian, thanks for raising this, I noticed that we had a new problem once protobuf was fixed for building criu.
On Tue, Jan 13, 2026 at 09:39:07AM +0100, Guillem Jover wrote: > On Tue, 2026-01-13 at 01:11:10 +0200, Adrian Bunk wrote: > > On Mon, Jan 12, 2026 at 11:36:26PM +0100, Guillem Jover wrote: > > > 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. > > Sorry, I meant that it appeared as if it validated the options but did > nothing with them afterwards. But I see now that this only applies to > -flto, -flto-partition= and -fuse-ld=. The problem is that «-f <arg>» > is «--auxiliary <SHLIB>», so any option prefixed as such is misparsed > (and that's why the requirements for -shared). > > So, I initially removed the -f option from the man page change. And > was also thinking -l and -L were probably inappropriate as well. > > > > 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. > > (This looks wrong given the ld -f option semantics as mentioned above.) > > > 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. > > If a project is calling ld(1) directly, then this is going to be (in > theory) low level linker handling, so passing most options specified > for the compiler might be in general not appropriate. > > I had initially in my first reply, as an alternative, to ban its usage > for direct ld(1) calls, but removed it as it seemed a bit too harsh. > But I think you are right that if anything should be passed, then > pre-cooking a variable for direct ld(1) use is probably going to be the > better solution, because dpkg-buildflags should know if those options > are (in general) safe to pass regardless of the intended use. Although > I'm still not entirely sure this is even a good idea, and/or whether > this should be qualified in the man page, because it could still mangle > the intended semantics. > > So perhaps better the attached patch. I went for LD_LDFLAGS because > otherwise we get LDFLAGS_FOR_LD_FOR_BUILD (which seems meh, but open > to other suggestions). But I'm still considering whether to simply ban > its use with direct calls and not provide a direct ld(1) option, > although the current patch leaves this up to the maintainer to decide, > which is probably the best way forward. It is not entirely clear to me for src:criu how I should approach this change. In the most ideal case I would like to have something which I can forward upstream and not have to divege too long from upstream. But I'm following your discussion in this bug. Regards, Salvatore
