Hi! On Tue, 2026-01-13 at 20:27:35 +0100, Salvatore Bonaccorso wrote: > 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: > > > 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.
Checking now criu, I think my position is now that given that there's no standardized variable to use for direct ld(1) calls (I mean we could just declare one as such, but…), and such projects might be mixing them with other linker calls done via the compiler, so passing these might be tricky or imply modifying upstream code anyway, there's currently no point in providing pre-cooked flags for such use, so I'll go for now with changing the documentation to ban their use, and explain what can be done on the upstream codebase instead. As an exercise to see how this could be approached, I fixed criu into that direction, as it was already partially doing this. The attached patch does that, and in addition it now properly preserves hardening flags for the linking done with both the compiler and directly with the linker, and does not unconditionally strip -Wl from the compiler calls (which seems incorrect to me). (Checked the difference by building before and after the patch and diffing the logs.) Thanks, Guillem
From f9494d5cff8be83fa7d8870b4d29ab76e10cc912 Mon Sep 17 00:00:00 2001 From: Guillem Jover <[email protected]> Date: Thu, 15 Jan 2026 00:14:21 +0100 Subject: [PATCH] Filter LDFLAGS for direct ld calls We should not be mixing flags intended for direct ld calls, and ones being used for linking via the compiler. Modify the filter so that we only allow a set of known options (-l and -L), and then remap the options intended for the linker passed as -Wl. --- criu/pie/Makefile | 2 +- scripts/nmk/scripts/build.mk | 24 ++++++++++++++++-------- 2 files changed, 17 insertions(+), 9 deletions(-) diff --git a/criu/pie/Makefile b/criu/pie/Makefile index 60c7f1e..7f34a67 100644 --- a/criu/pie/Makefile +++ b/criu/pie/Makefile @@ -10,7 +10,7 @@ ccflags-y += -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=0 ccflags-y += -Wp,-U_FORTIFY_SOURCE -Wp,-D_FORTIFY_SOURCE=0 ifneq ($(filter-out clean mrproper,$(MAKECMDGOALS)),) - LDFLAGS += $(shell $(COMPEL_BIN) ldflags) + LD_LDFLAGS += $(shell $(COMPEL_BIN) ldflags) compel_plugins := $(shell $(COMPEL_BIN) plugins) endif diff --git a/scripts/nmk/scripts/build.mk b/scripts/nmk/scripts/build.mk index d01d2b7..29ec0d9 100644 --- a/scripts/nmk/scripts/build.mk +++ b/scripts/nmk/scripts/build.mk @@ -40,13 +40,21 @@ __nmk-makefile-deps += $(src-makefile) export __nmk-makefile-deps # -# Filter out any -Wl,XXX option: some of build farms -# assumes that we're using $(CC) for building built-in -# targets (and they have all rights to). But we're -# using $(LD) directly instead so filter out -Wl -# flags to make maintainer's life easier. -LDFLAGS-MASK := -Wl,% -LDFLAGS := $(filter-out $(LDFLAGS-MASK),$(LDFLAGS)) +# Remap linker flags: Some build farms assumes that we're using $(CC) +# for building built-in targets (and they have all rights to). But +# we're using $(LD) directly instead so we need to accept only safe +# options (-l and -L), and remap -Wl,* so that these are accepted by $(LD), +# to make the maintainer's life easier. +NULLSTRING := +COMMA := , +SPACE := $(NULLSTRING) # EOL +LDFLAGS-REMAP := -Wl,% +LDFLAGS-ALLOW := -l% -L% +LDFLAGS-Wl := $(filter $(LDFLAGS-REMAP),$(LDFLAGS)) +LD_LDFLAGS := \ + $(filter $(LDFLAGS-ALLOW),$(LDFLAGS)) \ + $(subst $(COMMA),$(SPACE),$(subst -Wl,,$(LDFLAGS-Wl))) \ + # EOL # # Accumulate common flags. @@ -111,7 +119,7 @@ builtin-name := $(strip $(builtin-name)) # # Link flags. -ldflags-y := $(strip $(LDFLAGS) $(ldflags-y)) +ldflags-y := $(strip $(LD_LDFLAGS) $(ldflags-y)) # # $(obj) related rules. -- 2.51.0
