[I'm not subscribed, so please CC me on replies] Hi Daniel
On Fri, 21 Aug 2026 22:02:05 +0200 Daniel Lange <[email protected]> wrote:
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-gnux32Those 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
The question then is: why is this only necessary on those architectures?
2) Drop CLAT on the affected architectures until upstream fixes the problem:
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.
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
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
OpenPGP_signature.asc
Description: OpenPGP digital signature
