Bug#1145004: Mixed native platform and eBPF compile

Hi Michael,

Am 22.08.26 um 15:40 schrieb Michael Biebl:
>> 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?

Dunno. The headers are missing and can be found in the g++-multilib.
The NetworkManager upstream copied src/core/bpf/meson.build from
https://github.com/systemd/systemd/pull/20429 by their own account and ... probably did not fully understand the code.

As stated before, this is a build issue in NetworkManager and adding g++-multilib is a hack, not a proper fix.

[from your other email:]
> I tried that on a porterbox (perotto).
> 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. 

You chose the one arch where -D_CALL_ELF=2 does not work. Afaik it can only do ELF ABI v1.
So you run into that additional build problem on this arch.

Cf. ELF ABI v2

https://packages.debian.org/search?searchon=contents&keywords=gnu%2Fstubs-64-v2.h&mode=path&suite=unstable&arch=any

vs. ELF ABI v1

https://packages.debian.org/search?searchon=contents&keywords=gnu%2Fstubs-64-v1.h&mode=path&suite=unstable&arch=any

>> 2) Drop CLAT on the affected architectures until upstream fixes the 
>> problem:
>>
> 
> gcc upstream, meson upstream or NetworkManager upstream?

NetworkManager upstream
(yes, the Debian bug points wrong atm)

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

Ack. Then leave it broken until upstream fixes it.
If you ever change your mind and want newer NetworkManager on the niche arches, you can just disable building the CLAT BPF code.

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

$ git diff meson.build
diff --git a/src/core/bpf/meson.build b/src/core/bpf/meson.build
index 39b978dd..97d76511 100644
--- a/src/core/bpf/meson.build
+++ b/src/core/bpf/meson.build
@@ -166,25 +166,6 @@ endif
  
  bpf_o_unstripped_cmd += ['-I.']
  
-if cc.get_id() == 'gcc' or meson.is_cross_build()
-  if cc.get_id() != 'gcc'
-    warning('Cross compiler is not gcc. Guessing the target triplet for bpf likely fails.')
-  endif
-  target_triplet_cmd = run_command(cc.cmd_array(), '-print-multiarch', check: false)
-else
-  # clang does not support -print-multiarch (D133170) and its -dump-machine
-  # does not match multiarch. Query gcc instead.
-  target_triplet_cmd = run_command('gcc', '-print-multiarch', check: false)
-endif
-
-if target_triplet_cmd.returncode() == 0
-  target_triplet = target_triplet_cmd.stdout().strip()
-  bpf_o_unstripped_cmd += [
-    '-isystem',
-    '/usr/include/@0@'.format(target_triplet)
-  ]
-endif
-
  bpf_o_unstripped_cmd += [
    '-idirafter',
    libbpf_include_dir,

===

untested, but that's what I meant.

Happy hacking,
Daniel