Package: gcc-bpf
Version: 21
Severity: normal
X-Debbugs-Cc: debian-amd64@lists.debian.org, debian-powerpc@lists.debian.org, debian-sparc@lists.debian.org
User: debian-powerpc@lists.debian.org
Usertags: ppc64
User: debian-sparc@lists.debian.org
Usertags: sparc64
User: debian-x32@lists.debian.org
Usertags: x32

In https://salsa.debian.org/utopia-team/network-manager/-/merge_requests/18
support for CLAT (464XLAT) in NetworkManager was enabled.
It is implemented using an eBPF program.

This resulted in build failures on ppc64, sparc64 and x32 (and alpha).


ppc64
=====
https://buildd.debian.org/status/fetch.php?pkg=network-manager&arch=ppc64&ver=1.58.0-3&stamp=1786826236&raw=0

/usr/bin/bpf-gcc -std=gnu17 -Wunused -Wimplicit-fallthrough -fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c -D__powerpc64__ -D__TARGET_ARCH_powerpc -D_CALL_ELF=2 -mbig-endian -I. -isystem /usr/include/powerpc64-linux-gnu -idirafter /usr/include ../src/core/bpf/clat.bpf.c -o src/core/bpf/clat.bpf.unstripped.o
In file included from /usr/include/features.h:563,
                 from /usr/include/powerpc64-linux-gnu/sys/socket.h:22,
                 from /usr/include/linux/if.h:28,
                 from /usr/include/linux/icmp.h:23,
                 from ../src/core/bpf/clat.bpf.c:16:
/usr/include/powerpc64-linux-gnu/gnu/stubs.h:14:11: fatal error: gnu/stubs-64-v2.h: No such file or directory
   14 | # include <gnu/stubs-64-v2.h>
      |           ^~~~~~~~~~~~~~~~~~~
compilation terminated.

sparc64
=======
https://buildd.debian.org/status/fetch.php?pkg=network-manager&arch=sparc64&ver=1.58.0-3&stamp=1786827038&raw=0

/usr/bin/bpf-gcc -std=gnu17 -Wunused -Wimplicit-fallthrough -fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c -D__sparc64__ -mbig-endian -I. -isystem /usr/include/sparc64-linux-gnu -idirafter /usr/include ../src/core/bpf/clat.bpf.c -o src/core/bpf/clat.bpf.unstripped.o
In file included from /usr/include/features.h:563,
                 from /usr/include/sparc64-linux-gnu/sys/socket.h:22,
                 from /usr/include/linux/if.h:28,
                 from /usr/include/linux/icmp.h:23,
                 from ../src/core/bpf/clat.bpf.c:16:
/usr/include/sparc64-linux-gnu/gnu/stubs.h:8:11: fatal error: gnu/stubs-32.h: No such file or directory
    8 | # include <gnu/stubs-32.h>
      |           ^~~~~~~~~~~~~~~~
compilation terminated.

x32
===
https://buildd.debian.org/status/fetch.php?pkg=network-manager&arch=sparc64&ver=1.58.0-3&stamp=1786827038&raw=0

/usr/bin/bpf-gcc -std=gnu17 -Wunused -Wimplicit-fallthrough -fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c -D__x86_64__ -mlittle-endian -I. -isystem /usr/include/x86_64-linux-gnux32 -idirafter /usr/include ../src/core/bpf/clat.bpf.c -o src/core/bpf/clat.bpf.unstripped.o
In file included from /usr/include/features.h:563,
                 from /usr/include/x86_64-linux-gnux32/sys/socket.h:22,
                 from /usr/include/linux/if.h:28,
                 from /usr/include/linux/icmp.h:23,
                 from ../src/core/bpf/clat.bpf.c:16:
/usr/include/x86_64-linux-gnux32/gnu/stubs.h:10:11: fatal error: gnu/stubs-64.h: No such file or directory
   10 | # include <gnu/stubs-64.h>
      |           ^~~~~~~~~~~~~~~~
compilation terminated.


On IRC, jrtc27 and waldi said this:

jrtc27
======
sparc64 is identified by __sparc__ && __arch64__, there is no __sparc64__ in the linux world
(some BSDs do however use it)
note __aarch64__ != __aarch64__ :)
... sigh I mistyped it there, just proves my point
__arch64__ != __aarch64__
waldi
=====
jrtc27: so the -D__sparc64__ was never correct
jrtc27
======
it's never been the right define for sparc64-linux-gnu, no
some software recognises it because it's confused
some software recognises it because of BSDs
(and some software recognises __sparcv9__ because of solaris)
some software recognises it because it's confused
https://wiki.debian.org/ArchitectureSpecificsMemo#Summary is your friend



Regards,
Michael

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

[I'm not subscribed, so please CC me on replies]

Hi Daniel


gcc upstream, meson upstream or NetworkManager upstream?

I'd rather have a proper fix tbh and given that those are only ports,
it's not that pressing.

Which cross-build logic do you have in mind here in particular?

I do see a couple or architecture speficic defines at
https://salsa.debian.org/utopia-team/network-manager/-/blob/debian/latest/src/core/bpf/meson.build?ref_type=heads#L133-143

Interestingly no sparc64 and x32 specific build flags.

Could you mark the code, that you deem problematic?

Michael

Am 22.08.26 um 15:40 schrieb Michael Biebl:
It did not help. The build failure is the same.

$ apt-cache policy g++-multilib
g++-multilib:
   Installed: 4:16.1.0-3
   Candidate: 4:16.1.0-3
   Version table:
  *** 4:16.1.0-3 500
         500 http://deb.debian.org/debian-ports sid/main ppc64 Packages
         100 /var/lib/dpkg/status


$ ninja
[1/58] Generating src/core/bpf/clat.bpf.unstripped.o with a custom command
FAILED: [code=1] src/core/bpf/clat.bpf.unstripped.o
/usr/bin/bpf-gcc -std=gnu17 -Wunused -Wimplicit-fallthrough
-fno-stack-protector -fno-ssa-phiopt -O2 -mcpu=v3 -mco-re -gbtf -c 
-D__powerpc64__ -D__TARGET_ARCH_powerpc -D_CALL_ELF=2 -mbig-endian -I. 
-isystem /usr/include/powerpc64-linux-gnu -idirafter /usr/include 
../src/core/bpf/clat.bpf.c -o src/core/bpf/clat.bpf.unstripped.o
In file included from /usr/include/features.h:563,
                  from /usr/include/powerpc64-linux-gnu/sys/socket.h:22,
                  from /usr/include/linux/if.h:28,
                  from /usr/include/linux/icmp.h:23,
                  from ../src/core/bpf/clat.bpf.c:16:
/usr/include/powerpc64-linux-gnu/gnu/stubs.h:14:11: fatal error:
gnu/stubs-64-v2.h: No such file or directory
    14 | # include <gnu/stubs-64-v2.h>
       |           ^~~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.