Hi Michael,
the issue here is that the BPF compiler is made to consume the target
architecture's glibc userspace headers as if it were compiling normal
target userspace code.
bpf-gcc is compiling for the BPF target, while the build explicitly adds:
/usr/include/powerpc64-linux-gnu
/usr/include/sparc64-linux-gnu
/usr/include/x86_64-linux-gnux32
Those headers eventually pull in gnu/stubs.h, whose ABI selection
expects multilib glibc headers that aren't installed in the build
environment.
And should not be. Still you could provide them :).
1) I.e., you can add the (useless) target arch headers and make it compile:
Build-depend on g++-multilib
2) Drop CLAT on the affected architectures until upstream fixes the problem:
diff --git a/debian/rules b/debian/rules
index 76a5728a..064fc2e6 100755
--- a/debian/rules
+++ b/debian/rules
@@ -10,6 +10,17 @@ export PYTHON=/usr/bin/python3
PPPD_PLUGIN_DIR := $(shell dh_ppp --plugin-dir)
+# GCC's BPF target currently gets the target's multiarch libc include
+# directory from NetworkManager's Meson build. On architectures where
+# the corresponding multilib glibc headers are not installed, this causes
+# bpf-gcc to include gnu/stubs.h and fail. Disable CLAT until the BPF
+# include-path handling is fixed upstream.
+ifeq ($(filter $(DEB_HOST_ARCH),ppc64 sparc64 x32),)
+CLAT_OPTION := -Dclat=true
+else
+CLAT_OPTION := -Dclat=false
+endif
+
%:
dh $@ --with ppp
@@ -54,7 +65,7 @@ override_dh_auto_configure:
-Dovs=true \
-Dqt=false \
-Debpf=false \
- -Dclat=true \
+ $(CLAT_OPTION) \
-Dbpf-compiler=gcc \
-Dnbft=false \
-Dofono=true
3) Fix the upstream meson build. This is a bit out of scope for Debian
packaging but if you wanna do upstream work:
Removing the (useless) cross-build logic in src/core/*bpf*/meson.build
should™ fix it.
Kind regards,
Daniel
