On 3/12/20 6:59 PM, Andrii Nakryiko wrote:
On Thu, Mar 12, 2020 at 6:04 AM Tobias Klauser <tklauser@xxxxxxxxxx> wrote:When compiling bpftool on a system where the /usr/include/asm symlink doesn't exist (e.g. on an Ubuntu system without gcc-multilib installed), the build fails with: CLANG skeleton/profiler.bpf.o In file included from skeleton/profiler.bpf.c:4: In file included from /usr/include/linux/bpf.h:11: /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found #include <asm/types.h> ^~~~~~~~~~~~~ 1 error generated. make: *** [Makefile:123: skeleton/profiler.bpf.o] Error 1 This indicates that the build is using linux/types.h from system headers instead of source tree headers. To fix this, adjust the clang search path to include the necessary headers from tools/testing/selftests/bpf/include/uapi and tools/include/uapi. Also use __bitwise__ instead of __bitwise in skeleton/profiler.h to avoid clashing with the definition in tools/testing/selftests/bpf/include/uapi/linux/types.h. Cc: Daniel Borkmann <daniel@xxxxxxxxxxxxx> Cc: Song Liu <songliubraving@xxxxxx> Cc: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> Cc: Quentin Monnet <quentin@xxxxxxxxxxxxx> Signed-off-by: Tobias Klauser <tklauser@xxxxxxxxxx> --- tools/bpf/bpftool/Makefile | 5 ++++- tools/bpf/bpftool/skeleton/profiler.h | 17 ++++++++--------- 2 files changed, 12 insertions(+), 10 deletions(-) diff --git a/tools/bpf/bpftool/Makefile b/tools/bpf/bpftool/Makefile index 20a90d8450f8..f294f6c1e795 100644 --- a/tools/bpf/bpftool/Makefile +++ b/tools/bpf/bpftool/Makefile @@ -120,7 +120,10 @@ $(OUTPUT)_bpftool: $(_OBJS) $(LIBBPF) $(QUIET_LINK)$(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(_OBJS) $(LIBS) skeleton/profiler.bpf.o: skeleton/profiler.bpf.c - $(QUIET_CLANG)$(CLANG) -I$(srctree)/tools/lib -g -O2 -target bpf -c $< -o $@ + $(QUIET_CLANG)$(CLANG) \ + -I$(srctree)/tools/include/uapi/ \ + -I$(srctree)/tools/testing/selftests/bpf/include/uapi \Seems like I'm spoiling all the fun today :) But why are we ok with bpftool build depending on selftests? This just makes it even harder to have a stand-alone bpftool build eventually (similar to libbpf's Github).
I suspect the Github copy of bpftool would have its own include infra like in case of libbpf [0]? Agree in any case that it's not an optimal situation with this dependency; I suspect we might need the tools/testing/selftests/bpf/include/uapi/ under tools/include/uapi/ in a proper way. [0] https://github.com/libbpf/libbpf/tree/master/include
