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)