| Message ID | 20180430071730.nghfksp2tkj3x5ld@vm4 |
|---|---|
| State | Changes Requested, archived |
| Delegated to: | BPF Maintainers |
| Headers | show |
| Series | selftests/bpf | expand |
On 04/30/2018 09:17 AM, Sirio Balmelli wrote: > Build fails with missing 'asm/bitsperlong.h'. > > Include this from tools/arch/[arch]/include/uapi > using an architecture-specific include sourced from 'Module.symvers' > (is this legitimate? another idea was to do a `uname -p` but what if > caller was cross-compiling?) To point to an arch specific include, the way this works under tools can be seen e.g. in barrier.h, see tools/include/asm/barrier.h. This will then pull in one of the tools/arch/*/include/asm/barrier.h. We would need to do something similar for tools/arch/*/include/uapi/asm/bitsperlong.h Then you also don't need the Module.symvers hack to derive the underlying arch. See 720f228e8d31 ("bpf: fix broken BPF selftest build") for another, similar example we had in the past. > Once the arch-specific include is fixed, a lack of 'asm/byteorder.h' > now rears its ugly head. > The only sane (ie: will not pull in kernel headers) place I can find it > is in $(ROOT)/usr/include - add this to the include. Why it doesn't work adding a new file tools/include/uapi/asm/byteorder.h that points to one present in tools/arch/*/include/uapi/asm/bitsperlong.h or tools/include/uapi/asm-generic/bitsperlong.h otherwise? > Note that $(ROOT)/usr/include is generated on kernel build, hence my > assumption that 'Module.symvers' will also be present. The problem with this approach is that you need to do 'make header_install' in order to resolve this dependency, whereas tools infrastructure has no such dependency. Here's some more background context on the tools infra that perhaps helps why it's done this way: https://www.spinics.net/lists/netdev/msg487309.html Please see to add a tools/include/uapi/asm/byteorder.h to fix the issue. Thanks a lot, Daniel
diff --git a/tools/testing/selftests/bpf/Makefile b/tools/testing/selftests/bpf/Makefile index 9d76218..a19c6af 100644 --- a/tools/testing/selftests/bpf/Makefile +++ b/tools/testing/selftests/bpf/Makefile @@ -84,8 +84,14 @@ else CPU ?= generic endif -CLANG_FLAGS = -I. -I./include/uapi -I../../../include/uapi \ - -Wno-compare-distinct-pointer-types +# Assume caller has compiled the kernel; get compilation architecture from Module.symvers +TOOLS :=../../.. +ROOT :=../../../.. +ARCH := $(shell sed -rne 's|.*(arch/[^/]+).*|\1|p' $(ROOT)/Module.symvers | head -n 1) +CLANG_FLAGS = -I. -I./include/uapi \ + -I$(TOOLS)/include/uapi -I$(TOOLS)/$(ARCH)/include/uapi \ + -I$(ROOT)/usr/include \ + -Wno-compare-distinct-pointer-types $(OUTPUT)/test_l4lb_noinline.o: CLANG_FLAGS += -fno-inline $(OUTPUT)/test_xdp_noinline.o: CLANG_FLAGS += -fno-inline
Build fails with missing 'asm/bitsperlong.h'. Include this from tools/arch/[arch]/include/uapi using an architecture-specific include sourced from 'Module.symvers' (is this legitimate? another idea was to do a `uname -p` but what if caller was cross-compiling?) Once the arch-specific include is fixed, a lack of 'asm/byteorder.h' now rears its ugly head. The only sane (ie: will not pull in kernel headers) place I can find it is in $(ROOT)/usr/include - add this to the include. Note that $(ROOT)/usr/include is generated on kernel build, hence my assumption that 'Module.symvers' will also be present. This highlights a philosophical issue - should these tests build: 1. Against the kernel tree only? In this case I likely did the right thing here. 2. Against the local machine? Then the proper handling is to source 'arch' from eg `uname -p` and include /usr/include/x86_64-linux-gnu/asm/byteorder.h instead of $(ROOT)/usr/include. Signed-off-by: Sirio Balmelli <sirio@b-ad.ch> --- tools/testing/selftests/bpf/Makefile | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)