[Buildroot] [PATCH v1] libv4l: add missing bpf_common.h header

Peter Korsgaard peter at korsgaard.com
Wed Nov 7 16:59:03 UTC 2018

>>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice at gmail.com> writes:


 > Thanks for submitting this patch however build failures remain on some
 > architectures (ARM cortex a8 / a9 / arm926ej-s) with "old" kernel
 > headers (3.13) :
 > - http://autobuild.buildroot.org/results/b48/b48f9b284102d94b847a35ed1ca50a157fbcb1c9/build-end.log
 > - http://autobuild.buildroot.org/results/339/3391705aca7022111ef743212b7cad57f0cdea9a/build-end.log

 > Build failures are raised because _NR_bpf is not defined:

 > bpf.c:48:4: error: #error __NR_bpf not defined. libbpf does not
 > support your arch.
 >  #  error __NR_bpf not defined. libbpf does not support your arch.

 > From my understanding, __NR_bpf should be normally defined by the
 > kernel (when it is not too old).
 > For example, __NR_bpf has been defined for m68k and powerpc since 3.18:
 > - https://github.com/torvalds/linux/commit/f7bbd12a4b7e088f53f20dd31019984459699fb9
 > - https://github.com/torvalds/linux/commit/fcbb539f279f7d854bd49819b889fea0612909f8
 > The code in bpf.c only defines fallback for very few few
 > architectures: i386, x86_64, aarch64, sparc and s390.

But the fallback only fixes setups with older kernel headers than the
runtime kernel, which is IMHO fairly rare in Buildroot - Unless the tool
works correctly when the bpf syscall fails.

 > So finally, should we add a dependency on

The BPF_PROTOCOLS conditional seems to be about using clang to compile
bdf byte code, which is not directly the code that is failing here.

If it is easy to disable bpf support completely, then that is probably
the nicest solution, otherwise I am fine with depending on 3.18, that is
after all almost 4 years old by now.

Bye, Peter Korsgaard

More information about the buildroot mailing list