Installing Dependencies on Raspberry Pi 4 (armhf)

[IamPurpleRed]

I'm new here, and I'm using a Raspberry Pi 4B with the Raspberry Pi Buster OS (armhf). While I understand it is an outdated system, due to personal requirements, I'm still using it but have upgraded the Kernel to version 6.6.

I followed the steps outlined in setup_dependencies.org, but encountered some issues specific to my armhf architecture:

1. I was unable to install libc6-dev-i386 since it's not available for armhf. Is there an alternative package or method that I can use to meet this dependency?

2. I installed bpftool from buster-backports, but when I ran ./configure, the tool could not be found.

Below is the output from the command:

# pi@raspberrypi:~/xdp-tutorial $ sudo apt list --installed bpftool
Listing... Done
bpftool/buster-backports,now 5.10.127-2~bpo10+1 armhf [installed]

# pi@raspberrypi:~/xdp-tutorial $ ./configure
clang: 11.0.1-2~deb10u1+rpi1
libbpf support: submodule
ELF support: yes
zlib support: yes
libxdp support: submodule
Configuring libxdp to use our libbpf submodule
Found clang binary 'clang' with version 11 (from 'Raspbian clang version 11.0.1-2~deb10u1+rpi1')
not using emacs: 
/usr/sbin/bpftool
bpftool not found or doesn't support skeleton generation; not building all tools
libbpf support: custom v1.2.0
  perf_buffer__consume support: yes
  btf__load_from_kernel_by_id support: yes
  btf__type_cnt support: yes
  bpf_object__next_map support: yes
  bpf_object__next_program support: yes
  bpf_program__insn_cnt support: yes
  bpf_program__type support: yes
  bpf_program__flags support: yes
  bpf_program__expected_attach_type support: yes
  bpf_map_create support: yes
  perf_buffer__new_raw support: yes
  bpf_xdp_attach support: yes
  bpf_map__set_autocreate support: yes
  bpf_prog_test_run_opts support: yes
  bpf_xdp_query support: yes
zlib support: yes
ELF support: yes
pcap support: yes
secure_getenv support: yes
cap-ng support: no
*** ERROR - Clang BPF-prog cannot include <errno.h>
          - Install missing userspace header file

Compile error: In file included from config.QdbXQ8/bpf_use_errno_test.c:1:
In file included from /usr/include/errno.h:25:
In file included from /usr/include/features.h:448:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found
# include <gnu/stubs-soft.h>
          ^~~~~~~~~~~~~~~~~~
1 error generated.

 On Fedora install:
   dnf install glibc-devel.i686
 On Debian install:
   apt install libc6-dev-i386

I noticed that in issue #86, someone reported that arm32 was working, but that was 4 years ago. I'm not sure if it still applies today.

Could you please provide guidance or suggest alternative solutions for these issues?

Thank you for your help!

[tohojo]

Zih-Hong Lin @.***> writes:

I'm new here, and I'm using a Raspberry Pi 4B with the Raspberry Pi Buster OS (armhf). While I understand it is an outdated system, due to personal requirements, I'm still using it but have upgraded the Kernel to version 6.6.

I followed the steps outlined in setup_dependencies.org, but encountered some issues specific to my armhf architecture:

1. I was unable to install libc6-dev-i386 since it's not available for armhf. Is there an alternative package or method that I can use to meet this dependency?

2. I installed bpftool from buster-backports, but when I ran ./configure, the tool could not be found.

Below is the output from the command:

# ***@***.***:~/xdp-tutorial $ sudo apt list --installed bpftool
Listing... Done
bpftool/buster-backports,now 5.10.127-2~bpo10+1 armhf [installed]

# ***@***.***:~/xdp-tutorial $ ./configure
clang: 11.0.1-2~deb10u1+rpi1
libbpf support: submodule
ELF support: yes
zlib support: yes
libxdp support: submodule
Configuring libxdp to use our libbpf submodule
Found clang binary 'clang' with version 11 (from 'Raspbian clang version 11.0.1-2~deb10u1+rpi1')
not using emacs: 
/usr/sbin/bpftool
bpftool not found or doesn't support skeleton generation; not building all tools
libbpf support: custom v1.2.0
  perf_buffer__consume support: yes
  btf__load_from_kernel_by_id support: yes
  btf__type_cnt support: yes
  bpf_object__next_map support: yes
  bpf_object__next_program support: yes
  bpf_program__insn_cnt support: yes
  bpf_program__type support: yes
  bpf_program__flags support: yes
  bpf_program__expected_attach_type support: yes
  bpf_map_create support: yes
  perf_buffer__new_raw support: yes
  bpf_xdp_attach support: yes
  bpf_map__set_autocreate support: yes
  bpf_prog_test_run_opts support: yes
  bpf_xdp_query support: yes
zlib support: yes
ELF support: yes
pcap support: yes
secure_getenv support: yes
cap-ng support: no
*** ERROR - Clang BPF-prog cannot include <errno.h>
          - Install missing userspace header file

Compile error: In file included from config.QdbXQ8/bpf_use_errno_test.c:1:
In file included from /usr/include/errno.h:25:
In file included from /usr/include/features.h:448:
/usr/include/arm-linux-gnueabihf/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-soft.h' file not found
# include <gnu/stubs-soft.h>
          ^~~~~~~~~~~~~~~~~~
1 error generated.

 On Fedora install:
   dnf install glibc-devel.i686
 On Debian install:
   apt install libc6-dev-i386

I noticed that in issue #86, someone reported that arm32 was working, but that was 4 years ago. I'm not sure if it still applies today.

Could you please provide guidance or suggest alternative solutions for these issues?

Well, you'll have to figure out which package contains the /usr/include/gnu/stubs-soft.h header file. I don't use Debian on ARM, so no idea what that is; but maybe there's a differen 'libc6-dev-**' package or something?

As for bpftool, the version in backports is too old to be useful, but that should not affect your ability to run the tutorial itself...

[IamPurpleRed]

Well, you'll have to figure out which package contains the /usr/include/gnu/stubs-soft.h header file. I don't use Debian on ARM, so no idea what that is; but maybe there's a differen 'libc6-dev-**' package or something?

@tohojo thanks for your reply.

Debian on arm32 also has libc6-dev package, but it only has stubs-hard.h:

# pi@raspberrypi:~ $ sudo apt list libc6-dev
Listing... Done
libc6-dev/oldoldstable,now 2.28-10+rpt2+rpi1+deb10u2 armhf [installed,automatic]
N: There is 1 additional version. Please use the '-a' switch to see it
# pi@raspberrypi:~ $ ls /usr/include/arm-linux-gnueabihf/gnu/
libc-version.h  lib-names.h  lib-names-hard.h  stubs.h  stubs-hard.h

Well, it took me the whole afternoon to figure out what these were and how to solve it.

First, I tried ./configure CFLAGS="-mfloat-abi=hard" CXXFLAGS="-mfloat-abi=hard", but it didn't seem to work.

Later I found the libc6-dev-armel-cross package and installed it. stubs-soft.h is located at /usr/arm-linux-gnueabi/gnu/.

But running ./configure still defaults to searching the old path (/usr/include/arm-linux-gnueabihf/gnu/).

Since it's in a different path, I have no idea how to proceed.

[tohojo]

Zih-Hong Lin @.***> writes:

Well, you'll have to figure out which package contains the /usr/include/gnu/stubs-soft.h header file. I don't use Debian on ARM, so no idea what that is; but maybe there's a differen 'libc6-dev-**' package or something?

@tohojo thanks for your reply.

Debian on arm32 also has libc6-dev package, but it only has stubs-hard.h:

# ***@***.***:~ $ sudo apt list libc6-dev
Listing... Done
libc6-dev/oldoldstable,now 2.28-10+rpt2+rpi1+deb10u2 armhf [installed,automatic]
N: There is 1 additional version. Please use the '-a' switch to see it
# ***@***.***:~ $ ls /usr/include/arm-linux-gnueabihf/gnu/
libc-version.h  lib-names.h  lib-names-hard.h  stubs.h  stubs-hard.h

Well, it took me the whole afternoon to figure out what these were and how to solve it.

First, I tried ./configure CFLAGS="-mfloat-abi=hard" CXXFLAGS="-mfloat-abi=hard", but it didn't seem to work.

Later I found the libc6-dev-armel-cross package and installed it. stubs-soft.h is located at /usr/arm-linux-gnueabi/gnu/.

But running ./configure still defaults to searching the old path (/usr/include/arm-linux-gnueabihf/gnu/).

Well, configure relies on the compiler notion of the arch name (from $CC -print-multiarch), which in this case seems to output something different.

We don't currently support overriding this when running, but I see no reason why we couldn't. So feel free to open a pull request to allow overriding ARCH_INCLUDES and/or ARCH_NAME in the configure script! Or, if you know of a better way of detecting this than $CC -print-multiarch, that would also be totally fine :)