diff mbox series

[bpf-next,2/3] bpftool: Prevent setting duplicate _GNU_SOURCE in Makefile

Message ID 507d699068777b78a5720e617c99fb19a9bb8a89.1728975031.git.vmalik@redhat.com (mailing list archive)
State Superseded
Delegated to: BPF
Headers show
Series selftests/bpf: Improve building with extra | expand

Checks

Context Check Description
bpf/vmtest-bpf-next-PR success PR summary
netdev/series_format success Posting correctly formatted
netdev/tree_selection success Clearly marked for bpf-next, async
netdev/ynl success Generated files up to date; no warnings/errors; no diff in generated;
netdev/fixes_present success Fixes tag not required for -next series
netdev/header_inline success No static functions without inline keyword in header files
netdev/build_32bit success Errors and warnings before: 6 this patch: 6
netdev/build_tools success Errors and warnings before: 0 (+1) this patch: 0 (+1)
netdev/cc_maintainers warning 2 maintainers not CCed: llvm@lists.linux.dev qmo@kernel.org
netdev/build_clang success Errors and warnings before: 7 this patch: 7
netdev/verify_signedoff success Signed-off-by tag matches author and committer
netdev/deprecated_api success None detected
netdev/check_selftest success No net selftest shell script
netdev/verify_fixes success No Fixes tag
netdev/build_allmodconfig_warn success Errors and warnings before: 9 this patch: 9
netdev/checkpatch success total: 0 errors, 0 warnings, 0 checks, 14 lines checked
netdev/build_clang_rust success No Rust files in patch. Skipping build
netdev/kdoc success Errors and warnings before: 0 this patch: 0
netdev/source_inline success Was 0 now: 0
bpf/vmtest-bpf-next-VM_Test-0 success Logs for Lint
bpf/vmtest-bpf-next-VM_Test-1 success Logs for ShellCheck
bpf/vmtest-bpf-next-VM_Test-3 success Logs for Validate matrix.py
bpf/vmtest-bpf-next-VM_Test-2 success Logs for Unittests
bpf/vmtest-bpf-next-VM_Test-5 success Logs for aarch64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-32 success Logs for x86_64-llvm-17 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-34 success Logs for x86_64-llvm-18 / build / build for x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-33 success Logs for x86_64-llvm-17 / veristat
bpf/vmtest-bpf-next-VM_Test-11 success Logs for s390x-gcc / build / build for s390x with gcc
bpf/vmtest-bpf-next-VM_Test-12 success Logs for s390x-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-15 success Logs for s390x-gcc / test (test_verifier, false, 360) / test_verifier on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-25 success Logs for x86_64-gcc / test (test_verifier, false, 360) / test_verifier on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-9 success Logs for aarch64-gcc / test (test_verifier, false, 360) / test_verifier on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-35 success Logs for x86_64-llvm-18 / build-release / build for x86_64 with llvm-18-O2
bpf/vmtest-bpf-next-VM_Test-10 success Logs for aarch64-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-4 success Logs for aarch64-gcc / build / build for aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-18 success Logs for x86_64-gcc / build / build for x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-19 success Logs for x86_64-gcc / build-release
bpf/vmtest-bpf-next-VM_Test-27 success Logs for x86_64-llvm-17 / build / build for x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-20 success Logs for x86_64-gcc / test (test_maps, false, 360) / test_maps on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-28 success Logs for x86_64-llvm-17 / build-release / build for x86_64 with llvm-17-O2
bpf/vmtest-bpf-next-VM_Test-29 success Logs for x86_64-llvm-17 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-17 success Logs for set-matrix
bpf/vmtest-bpf-next-VM_Test-16 success Logs for s390x-gcc / veristat
bpf/vmtest-bpf-next-VM_Test-36 success Logs for x86_64-llvm-18 / test (test_maps, false, 360) / test_maps on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-40 success Logs for x86_64-llvm-18 / test (test_verifier, false, 360) / test_verifier on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-41 success Logs for x86_64-llvm-18 / veristat
bpf/vmtest-bpf-next-VM_Test-6 success Logs for aarch64-gcc / test (test_maps, false, 360) / test_maps on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-7 success Logs for aarch64-gcc / test (test_progs, false, 360) / test_progs on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-8 success Logs for aarch64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on aarch64 with gcc
bpf/vmtest-bpf-next-VM_Test-37 success Logs for x86_64-llvm-18 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-38 success Logs for x86_64-llvm-18 / test (test_progs_cpuv4, false, 360) / test_progs_cpuv4 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-39 success Logs for x86_64-llvm-18 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-18
bpf/vmtest-bpf-next-VM_Test-31 success Logs for x86_64-llvm-17 / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-22 success Logs for x86_64-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-24 success Logs for x86_64-gcc / test (test_progs_parallel, true, 30) / test_progs_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-30 success Logs for x86_64-llvm-17 / test (test_progs, false, 360) / test_progs on x86_64 with llvm-17
bpf/vmtest-bpf-next-VM_Test-23 success Logs for x86_64-gcc / test (test_progs_no_alu32_parallel, true, 30) / test_progs_no_alu32_parallel on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-26 success Logs for x86_64-gcc / veristat / veristat on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-21 success Logs for x86_64-gcc / test (test_progs, false, 360) / test_progs on x86_64 with gcc
bpf/vmtest-bpf-next-VM_Test-13 success Logs for s390x-gcc / test (test_progs, false, 360) / test_progs on s390x with gcc
bpf/vmtest-bpf-next-VM_Test-14 success Logs for s390x-gcc / test (test_progs_no_alu32, false, 360) / test_progs_no_alu32 on s390x with gcc

Commit Message

Viktor Malik Oct. 15, 2024, 6:54 a.m. UTC 
When building selftests with CFLAGS set via env variable, the value of
CFLAGS is propagated into bpftool Makefile (called from selftests
Makefile). This makes the compilation fail as _GNU_SOURCE is defined two
times - once from selftests Makefile (by including lib.mk) and once from
bpftool Makefile (by calling `llvm-config --cflags`):

    $ CFLAGS="" make -C tools/testing/selftests/bpf
    [...]
    CC      /bpf-next/tools/testing/selftests/bpf/tools/build/bpftool/btf.o
    <command-line>: error: "_GNU_SOURCE" redefined [-Werror]
    <command-line>: note: this is the location of the previous definition
    cc1: all warnings being treated as errors
    [...]

Let bpftool Makefile check if _GNU_SOURCE is already defined and if so,
do not let llvm-config add it again.

Signed-off-by: Viktor Malik <vmalik@redhat.com>
---
 tools/bpf/bpftool/Makefile | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

Comments

Quentin Monnet Oct. 15, 2024, 10:03 a.m. UTC | #1 
2024-10-15 08:54 UTC+0200 ~ Viktor Malik <vmalik@redhat.com>
> When building selftests with CFLAGS set via env variable, the value of
> CFLAGS is propagated into bpftool Makefile (called from selftests
> Makefile). This makes the compilation fail as _GNU_SOURCE is defined two
> times - once from selftests Makefile (by including lib.mk) and once from
> bpftool Makefile (by calling `llvm-config --cflags`):
> 
>      $ CFLAGS="" make -C tools/testing/selftests/bpf
>      [...]
>      CC      /bpf-next/tools/testing/selftests/bpf/tools/build/bpftool/btf.o
>      <command-line>: error: "_GNU_SOURCE" redefined [-Werror]
>      <command-line>: note: this is the location of the previous definition
>      cc1: all warnings being treated as errors
>      [...]
> 
> Let bpftool Makefile check if _GNU_SOURCE is already defined and if so,
> do not let llvm-config add it again.
> 
> Signed-off-by: Viktor Malik <vmalik@redhat.com>
> ---
>   tools/bpf/bpftool/Makefile | 8 +++++++-
>   1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index ba927379eb20..2b5a713d71d8 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -147,7 +147,13 @@ ifeq ($(feature-llvm),1)
>     # If LLVM is available, use it for JIT disassembly
>     CFLAGS  += -DHAVE_LLVM_SUPPORT
>     LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
> -  CFLAGS  += $(shell $(LLVM_CONFIG) --cflags)
> +  # When bpftool build is called from another Makefile which already sets
> +  # -D_GNU_SOURCE, do not let llvm-config add it again as it will cause conflict.


Thanks! Can you please make your comment more explicit and mention the 
file tools/testing/selftests/lib.mk and/or the use case addressed 
(building bpftool from selftests), given that you match on the exact 
string "-D_GNU_SOURCE="? Your check won't skip adding the duplicate 
definition if someone passes "-D_GNU_SOURCE", without the "=", by 
calling the Makefile from another path; that's fine, but I don't want 
users to read the Makefile and expect it to remove the second definition 
in such a case.


> +  ifneq ($(filter -D_GNU_SOURCE=,$(CFLAGS)),)
> +    CFLAGS += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
> +  else
> +    CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
> +  endif

Looks good otherwise:

Reviewed-by: Quentin Monnet <qmo@kernel.org>
Viktor Malik Oct. 15, 2024, 10:17 a.m. UTC | #2 
On 10/15/24 12:03, Quentin Monnet wrote:
> 2024-10-15 08:54 UTC+0200 ~ Viktor Malik <vmalik@redhat.com>
>> When building selftests with CFLAGS set via env variable, the value of
>> CFLAGS is propagated into bpftool Makefile (called from selftests
>> Makefile). This makes the compilation fail as _GNU_SOURCE is defined two
>> times - once from selftests Makefile (by including lib.mk) and once from
>> bpftool Makefile (by calling `llvm-config --cflags`):
>>
>>      $ CFLAGS="" make -C tools/testing/selftests/bpf
>>      [...]
>>      CC      /bpf-next/tools/testing/selftests/bpf/tools/build/bpftool/btf.o
>>      <command-line>: error: "_GNU_SOURCE" redefined [-Werror]
>>      <command-line>: note: this is the location of the previous definition
>>      cc1: all warnings being treated as errors
>>      [...]
>>
>> Let bpftool Makefile check if _GNU_SOURCE is already defined and if so,
>> do not let llvm-config add it again.
>>
>> Signed-off-by: Viktor Malik <vmalik@redhat.com>
>> ---
>>   tools/bpf/bpftool/Makefile | 8 +++++++-
>>   1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
>> index ba927379eb20..2b5a713d71d8 100644
>> --- a/tools/bpf/bpftool/Makefile
>> +++ b/tools/bpf/bpftool/Makefile
>> @@ -147,7 +147,13 @@ ifeq ($(feature-llvm),1)
>>     # If LLVM is available, use it for JIT disassembly
>>     CFLAGS  += -DHAVE_LLVM_SUPPORT
>>     LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
>> -  CFLAGS  += $(shell $(LLVM_CONFIG) --cflags)
>> +  # When bpftool build is called from another Makefile which already sets
>> +  # -D_GNU_SOURCE, do not let llvm-config add it again as it will cause conflict.
> 
> 
> Thanks! Can you please make your comment more explicit and mention the 
> file tools/testing/selftests/lib.mk and/or the use case addressed 
> (building bpftool from selftests), given that you match on the exact 
> string "-D_GNU_SOURCE="? Your check won't skip adding the duplicate 
> definition if someone passes "-D_GNU_SOURCE", without the "=", by 
> calling the Makefile from another path; that's fine, but I don't want 
> users to read the Makefile and expect it to remove the second definition 
> in such a case.

Right, that's a good point, I'll expand the comment.

Thanks!

> 
> 
>> +  ifneq ($(filter -D_GNU_SOURCE=,$(CFLAGS)),)
>> +    CFLAGS += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
>> +  else
>> +    CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
>> +  endif
> 
> Looks good otherwise:
> 
> Reviewed-by: Quentin Monnet <qmo@kernel.org>
>
Andrii Nakryiko Oct. 16, 2024, 8:34 p.m. UTC | #3 
On Mon, Oct 14, 2024 at 11:55 PM Viktor Malik <vmalik@redhat.com> wrote:
>
> When building selftests with CFLAGS set via env variable, the value of
> CFLAGS is propagated into bpftool Makefile (called from selftests
> Makefile). This makes the compilation fail as _GNU_SOURCE is defined two
> times - once from selftests Makefile (by including lib.mk) and once from
> bpftool Makefile (by calling `llvm-config --cflags`):
>
>     $ CFLAGS="" make -C tools/testing/selftests/bpf
>     [...]
>     CC      /bpf-next/tools/testing/selftests/bpf/tools/build/bpftool/btf.o
>     <command-line>: error: "_GNU_SOURCE" redefined [-Werror]
>     <command-line>: note: this is the location of the previous definition
>     cc1: all warnings being treated as errors
>     [...]
>
> Let bpftool Makefile check if _GNU_SOURCE is already defined and if so,
> do not let llvm-config add it again.
>
> Signed-off-by: Viktor Malik <vmalik@redhat.com>
> ---
>  tools/bpf/bpftool/Makefile | 8 +++++++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index ba927379eb20..2b5a713d71d8 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -147,7 +147,13 @@ ifeq ($(feature-llvm),1)
>    # If LLVM is available, use it for JIT disassembly
>    CFLAGS  += -DHAVE_LLVM_SUPPORT
>    LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
> -  CFLAGS  += $(shell $(LLVM_CONFIG) --cflags)
> +  # When bpftool build is called from another Makefile which already sets
> +  # -D_GNU_SOURCE, do not let llvm-config add it again as it will cause conflict.
> +  ifneq ($(filter -D_GNU_SOURCE=,$(CFLAGS)),)
> +    CFLAGS += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))

why not always do filter-out and avoid this ugly ifneq?

> +  else
> +    CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
> +  endif
>    LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
>    ifeq ($(shell $(LLVM_CONFIG) --shared-mode),static)
>      LIBS += $(shell $(LLVM_CONFIG) --system-libs $(LLVM_CONFIG_LIB_COMPONENTS))
> --
> 2.47.0
>
Viktor Malik Oct. 17, 2024, 6:08 a.m. UTC | #4 
On 10/16/24 22:34, Andrii Nakryiko wrote:
> On Mon, Oct 14, 2024 at 11:55 PM Viktor Malik <vmalik@redhat.com> wrote:
>>
>> When building selftests with CFLAGS set via env variable, the value of
>> CFLAGS is propagated into bpftool Makefile (called from selftests
>> Makefile). This makes the compilation fail as _GNU_SOURCE is defined two
>> times - once from selftests Makefile (by including lib.mk) and once from
>> bpftool Makefile (by calling `llvm-config --cflags`):
>>
>>     $ CFLAGS="" make -C tools/testing/selftests/bpf
>>     [...]
>>     CC      /bpf-next/tools/testing/selftests/bpf/tools/build/bpftool/btf.o
>>     <command-line>: error: "_GNU_SOURCE" redefined [-Werror]
>>     <command-line>: note: this is the location of the previous definition
>>     cc1: all warnings being treated as errors
>>     [...]
>>
>> Let bpftool Makefile check if _GNU_SOURCE is already defined and if so,
>> do not let llvm-config add it again.
>>
>> Signed-off-by: Viktor Malik <vmalik@redhat.com>
>> ---
>>  tools/bpf/bpftool/Makefile | 8 +++++++-
>>  1 file changed, 7 insertions(+), 1 deletion(-)
>>
>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
>> index ba927379eb20..2b5a713d71d8 100644
>> --- a/tools/bpf/bpftool/Makefile
>> +++ b/tools/bpf/bpftool/Makefile
>> @@ -147,7 +147,13 @@ ifeq ($(feature-llvm),1)
>>    # If LLVM is available, use it for JIT disassembly
>>    CFLAGS  += -DHAVE_LLVM_SUPPORT
>>    LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
>> -  CFLAGS  += $(shell $(LLVM_CONFIG) --cflags)
>> +  # When bpftool build is called from another Makefile which already sets
>> +  # -D_GNU_SOURCE, do not let llvm-config add it again as it will cause conflict.
>> +  ifneq ($(filter -D_GNU_SOURCE=,$(CFLAGS)),)
>> +    CFLAGS += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
> 
> why not always do filter-out and avoid this ugly ifneq?

Because in that case, _GNU_SOURCE would not be defined for some builds
(e.g. plain bpftool build). I'm not entirely sure what the implications
are so I wanted to stay on the safe side. Anyways, I gave it a try and
bpftool builds without _GNU_SOURCE just fine so I think that we can drop
the ifneq.

> 
>> +  else
>> +    CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
>> +  endif
>>    LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
>>    ifeq ($(shell $(LLVM_CONFIG) --shared-mode),static)
>>      LIBS += $(shell $(LLVM_CONFIG) --system-libs $(LLVM_CONFIG_LIB_COMPONENTS))
>> --
>> 2.47.0
>>
>
diff mbox series

Patch

diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index ba927379eb20..2b5a713d71d8 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -147,7 +147,13 @@  ifeq ($(feature-llvm),1)
   # If LLVM is available, use it for JIT disassembly
   CFLAGS  += -DHAVE_LLVM_SUPPORT
   LLVM_CONFIG_LIB_COMPONENTS := mcdisassembler all-targets
-  CFLAGS  += $(shell $(LLVM_CONFIG) --cflags)
+  # When bpftool build is called from another Makefile which already sets
+  # -D_GNU_SOURCE, do not let llvm-config add it again as it will cause conflict.
+  ifneq ($(filter -D_GNU_SOURCE=,$(CFLAGS)),)
+    CFLAGS += $(filter-out -D_GNU_SOURCE,$(shell $(LLVM_CONFIG) --cflags))
+  else
+    CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
+  endif
   LIBS    += $(shell $(LLVM_CONFIG) --libs $(LLVM_CONFIG_LIB_COMPONENTS))
   ifeq ($(shell $(LLVM_CONFIG) --shared-mode),static)
     LIBS += $(shell $(LLVM_CONFIG) --system-libs $(LLVM_CONFIG_LIB_COMPONENTS))