When building either tools/bpf/bpftool, or tools/testing/selftests/hid,
(the same Makefile is used for these), clang generates many instances of
a warning that is useless here:
"clang: warning: -lLLVM-17: 'linker' input unused"
Silence this in both locations, by disabling that warning when building
with clang.
Signed-off-by: John Hubbard <[email protected]>
---
tools/bpf/bpftool/Makefile | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index e9154ace80ff..c7457921d136 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -133,6 +133,10 @@ CFLAGS += -DUSE_LIBCAP
LIBS += -lcap
endif
+ifneq ($(LLVM),)
+ CFLAGS += -Wno-unused-command-line-argument
+endif
+
include $(wildcard $(OUTPUT)*.d)
all: $(OUTPUT)bpftool
base-commit: f462ae0edd3703edd6f22fe41d336369c38b884b
prerequisite-patch-id: b901ece2a5b78503e2fb5480f20e304d36a0ea27
--
2.45.0
On 05/05/2024 22:56, John Hubbard wrote:
> When building either tools/bpf/bpftool, or tools/testing/selftests/hid,
> (the same Makefile is used for these), clang generates many instances of
> a warning that is useless here:
>
> "clang: warning: -lLLVM-17: 'linker' input unused"
>
> Silence this in both locations, by disabling that warning when building
> with clang.
>
> Signed-off-by: John Hubbard <[email protected]>
> ---
> tools/bpf/bpftool/Makefile | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
> index e9154ace80ff..c7457921d136 100644
> --- a/tools/bpf/bpftool/Makefile
> +++ b/tools/bpf/bpftool/Makefile
> @@ -133,6 +133,10 @@ CFLAGS += -DUSE_LIBCAP
> LIBS += -lcap
> endif
>
> +ifneq ($(LLVM),)
> + CFLAGS += -Wno-unused-command-line-argument
> +endif
Thanks! If possible, I'd rather keep the warning enabled, and fix the
command line instead. Looking at the error and the Makefile, we may not
need the -lLLVM<version> in the CFLAGS at all, but only in $(LIBS). On
my setup, I can build successfully, without the warnings, with the
following patch:
------
diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
index b67454b45a49..dfa4f1bebbb3 100644
--- a/tools/bpf/bpftool/Makefile
+++ b/tools/bpf/bpftool/Makefile
@@ -147,7 +147,7 @@ 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 --libs $(LLVM_CONFIG_LIB_COMPONENTS))
+ CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
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))
------
Could you please check whether that works on your side, too?
Quentin
On 05/05/2024 23:48, John Hubbard wrote:
> On 5/5/24 3:36 PM, Quentin Monnet wrote:
>> On 05/05/2024 22:56, John Hubbard wrote:
> ...
>> Thanks! If possible, I'd rather keep the warning enabled, and fix the
>> command line instead. Looking at the error and the Makefile, we may not
>> need the -lLLVM<version> in the CFLAGS at all, but only in $(LIBS). On
>> my setup, I can build successfully, without the warnings, with the
>> following patch:
>>
>> ------
>> diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile
>> index b67454b45a49..dfa4f1bebbb3 100644
>> --- a/tools/bpf/bpftool/Makefile
>> +++ b/tools/bpf/bpftool/Makefile
>> @@ -147,7 +147,7 @@ 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 --libs
>> $(LLVM_CONFIG_LIB_COMPONENTS))
>> + CFLAGS += $(shell $(LLVM_CONFIG) --cflags)
>> 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))
>> ------
>>
>> Could you please check whether that works on your side, too?
>>
>
> Yes, that works, and of course that's much better. Please let me
> know if you prefer me to post a v2 with that, or if you plan
> on sending it yourself?
Please go ahead!
Quentin