I ran into build issues when building selftests/net on Ubuntu/Debian,
which is related to that BPF program builds usually needs libc (and the
corresponding target host configuration/defines).
When I try to build selftests/net, on my Debian host I get:
clang -O2 -target bpf -c bpf/nat6to4.c -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
In file included from bpf/nat6to4.c:27:
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.
asm/types.h lives in /usr/include/"TRIPLE" on Debian, say
/usr/include/x86_64-linux-gnu. Target BPF does not (obviously) add the
x86-64 search path. These kind of problems have been worked around in,
e.g., commit 167381f3eac0 ("selftests/bpf: Makefile fix "missing"
headers on build with -idirafter").
However, just adding the host specific path is not enough. Typically,
when you start to include libc files, like "sys/socket.h" it's
expected that host specific defines are set. On my x86-64 host:
$ clang -dM -E - < /dev/null|grep x86_
#define __x86_64 1
#define __x86_64__ 1
$ clang -target riscv64-linux-gnu -dM -E - < /dev/null|grep xlen
#define __riscv_xlen 64
otherwise you end up with errors like the one below.
Missing __x86_64__:
#if !defined __x86_64__
# include <gnu/stubs-32.h>
#endif
clang -O2 -target bpf -c bpf/nat6to4.c -idirafter /usr/lib/llvm-16/lib/clang/16.0.0/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include -Wno-compare-distinct-pointer-types -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
In file included from bpf/nat6to4.c:28:
In file included from /usr/include/linux/if.h:28:
In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:22:
In file included from /usr/include/features.h:510:
/usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
# include <gnu/stubs-32.h>
^~~~~~~~~~~~~~~~
1 error generated.
Now, say that we'd like to cross-compile for a platform. Should I make
sure that all the target compiler's "default defines" are exported to
the BPF-program build step? I did a hack for RISC-V a while back in
commit 6016df8fe874 ("selftests/bpf: Fix broken riscv build"). Not
super robust, and not something I'd like to see for all supported
platforms.
Any ideas? Maybe a convenience switch to Clang/target bpf? :-)
Björn
