Bug#1145004: Mixed native platform and eBPF compile

[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-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

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

-----BEGIN PGP SIGNATURE-----

wsF5BAABCAAjFiEECbOsLssWnJBDRcxUauHfDWCPItwFAmqJps0FAwAAAAAACgkQauHfDWCPItyU
7xAAjGh7u3+C2+JO6QGQB0uCtTq0Z4J5qSyaWKBv+KnAL/lUWfFmUhCf3azn9FwGN7fmZkuuPajY
ZA5ZIFB69WvgkWXmDRnrIwnZznOz8Y1tML8T+tD/biPIclsVIVBHj0d2grYZfNizgLg+BvjU9bnE
H1RHClBxNmJjW3ZjaDaNqoLiKByC88uDeFOroCeZJVyBBZtOHCXmiu+o3T6bNaANd2BKCfaj7M2V
KZ1VAgezFAV+HX055aKmVuaf32Az1b9svgvlGE4JFwScEzUumN8j9ImnXdrtWPFDJHpZXzGhPEgY
Y3/EdF5U5qGxAWxfuJ4ZSAZFQGxebsR/Y2wyxE1ZI1BSu0zQ2tYZv48zK+n/HDlavrmpRQTkfymG
dsxjLL3JFBtwpZCJksZClgLitW4I81m5EbrWPp4gAwitHD0W1f4oXb4RgtOMmbSA13XWy9LPLcaK
KeLyWqboFS952jrSzfokZVOBUy6usc4UMOzwpihucFakaj8GoNDCi6ZU7p6JtP2af+uYlicDyzFI
gumdx8+eKYE19UGnXktJnOG3KykQR+KCupA8vGpNwVZTmjyJhrEitKGllvCzOhJImdBitlJ7hA/F
irMuZS9gC5TqZh76BqpEk0LNWYV6+Ce7iV3ITD0lH3wAZyAfTMUF83Elbb1UVf6NR4yHK59GHvSR
AHg=
=ZXKB
-----END PGP SIGNATURE-----