[PATCH v4 06/30] libbpf: Remove duplicate $(CLANG_CROSS_FLAGS)

Leo Yan posted 30 patches 4 weeks ago
There is a newer version of this series
[PATCH v4 06/30] libbpf: Remove duplicate $(CLANG_CROSS_FLAGS)
Posted by Leo Yan 4 weeks ago
tools/scripts/Makefile.include already appends $(CLANG_CROSS_FLAGS) to
CFLAGS:

  CFLAGS += $(CLANG_CROSS_FLAGS)

Since Makefile.include is included, the libbpf Makefile appends
$(CLANG_CROSS_FLAGS) again, resulting in duplicate flags.

Remove the redundant append.

Signed-off-by: Leo Yan <leo.yan@arm.com>
---
 tools/lib/bpf/Makefile | 1 -
 1 file changed, 1 deletion(-)

diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
index 168140f8e6461bd06db40e23d21a3fb8847ccbf4..b1fbd0211c5edde7be3d98630b16e53e028d9116 100644
--- a/tools/lib/bpf/Makefile
+++ b/tools/lib/bpf/Makefile
@@ -84,7 +84,6 @@ override CFLAGS += -Werror -Wall
 override CFLAGS += $(INCLUDES)
 override CFLAGS += -fvisibility=hidden
 override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-override CFLAGS += $(CLANG_CROSS_FLAGS)
 
 # flags specific for shared library
 SHLIB_FLAGS := -DSHARED -fPIC

-- 
2.34.1
Re: [PATCH v4 06/30] libbpf: Remove duplicate $(CLANG_CROSS_FLAGS)
Posted by bot+bpf-ci@kernel.org 4 weeks ago
> diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> index 168140f8e646..b1fbd0211c5e 100644
> --- a/tools/lib/bpf/Makefile
> +++ b/tools/lib/bpf/Makefile
> @@ -84,7 +84,6 @@ override CFLAGS += -Werror -Wall
>  override CFLAGS += $(INCLUDES)
>  override CFLAGS += -fvisibility=hidden
>  override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> -override CFLAGS += $(CLANG_CROSS_FLAGS)

At this commit, doesn't this removal lose CLANG_CROSS_FLAGS entirely
from the libbpf build?

The libbpf Makefile includes Makefile.include at the top, which does
append CLANG_CROSS_FLAGS to CFLAGS. But then the libbpf Makefile
overwrites CFLAGS with :=

    CFLAGS := -g -O2

which destroys everything Makefile.include appended. The removed line
above was the only thing that re-added the cross-compile flags after
that overwrite.

The next commit in the series (233d70853154 "libbpf: Initialize CFLAGS
before including Makefile.include") fixes this by moving the CFLAGS
initialization before the include, so Makefile.include's addition
survives. But at this commit, cross-compilation with Clang appears
broken.

Could these two patches be squashed or reordered so that the
initialization move comes first?


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/22943905432
Re: [PATCH v4 06/30] libbpf: Remove duplicate $(CLANG_CROSS_FLAGS)
Posted by Leo Yan 4 weeks ago
On Wed, Mar 11, 2026 at 09:02:13AM +0000, bot+bpf-ci@kernel.org wrote:
> > diff --git a/tools/lib/bpf/Makefile b/tools/lib/bpf/Makefile
> > index 168140f8e646..b1fbd0211c5e 100644
> > --- a/tools/lib/bpf/Makefile
> > +++ b/tools/lib/bpf/Makefile
> > @@ -84,7 +84,6 @@ override CFLAGS += -Werror -Wall
> >  override CFLAGS += $(INCLUDES)
> >  override CFLAGS += -fvisibility=hidden
> >  override CFLAGS += -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
> > -override CFLAGS += $(CLANG_CROSS_FLAGS)
> 
> At this commit, doesn't this removal lose CLANG_CROSS_FLAGS entirely
> from the libbpf build?
> 
> The libbpf Makefile includes Makefile.include at the top, which does
> append CLANG_CROSS_FLAGS to CFLAGS. But then the libbpf Makefile
> overwrites CFLAGS with :=
> 
>     CFLAGS := -g -O2
> 
> which destroys everything Makefile.include appended. The removed line
> above was the only thing that re-added the cross-compile flags after
> that overwrite.
> 
> The next commit in the series (233d70853154 "libbpf: Initialize CFLAGS
> before including Makefile.include") fixes this by moving the CFLAGS
> initialization before the include, so Makefile.include's addition
> survives. But at this commit, cross-compilation with Clang appears
> broken.
> 
> Could these two patches be squashed or reordered so that the
> initialization move comes first?

To be honest, I feel much more comfortable being corrected by a human
rather than a bot :)

The comment is fair enough, I will squash the two patches.

Thanks,
Leo