On 10/6/25 03:30, Demi Marie Obenour wrote:
The build happened to work on arm64 because the glibc arm64 headers don't support multilib. On x86_64, glibc headers assume that BPF is a 32-bit platform (because __x86_64__ isn't defined) and fail to find the 32-bit headers. This is not a glibc bug. Rather, BPF programs should not be including glibc headers.
Most Linux headers are not trivial to include in BPF programs. The version of the headers meant for userspace use do include glibc headers, and that isn't supported in BPF. The version meant for building kernel modules does not, but using it requires much more complicated build system.
Solve this problem by only including headers intended for use in BPF programs. These headers include declarations explicitly intended for use in BPF programs, so if they do pull in libc headers that is a bug. This also allows using an unwrapped clang. Nix's wrapped clang is not suitable when a target is explicitly specified, so this is another a bug fix.
This prevents vendoring the example headers, so replace them with a header that only includes common functionality common to both eBPF programs. A single struct including both Ethernet II and 802.1Q headers is used, massively simplifying the code.
Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
Build failures are because the compiler can't find <linux/bpf.h>. It appears that libbpf does not provide its own version of that file, and in any case the include path to find it is wrong. Using a wrapped compiler is wrong but might fix this. Another option, which I think is probably best, is to move this to vm/sys/net and build it against the headers from vm/sys/net's kernel. The build only requires the UAPI headers, which are stable, so any kernel build that is not truly ancient can be used. The correct include directory is "${kernel-pkg.dev}/lib/modules/${kernel-pkg.version}/source/include/uapi" where kernel-pkg is the Nix kernel package derivation. Also, Yureka, can you look at the (massive) changes to the C code? -- Sincerely, Demi Marie Obenour (she/her/hers)