From: Peter Seiderer <ps.report@gmx.net>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH v1] libv4l: add missing bpf_common.h header
Date: Wed, 7 Nov 2018 23:04:28 +0100 [thread overview]
Message-ID: <20181107230428.3a1e16fb@gmx.net> (raw)
In-Reply-To: <CAPi7W814qXc6DEGPm1c0z5oq4TGp66-xwcep-5t+OCL8fqCJaQ@mail.gmail.com>
Hello Fabrice,
On Wed, 7 Nov 2018 20:05:51 +0100, Fabrice Fontaine <fontaine.fabrice@gmail.com> wrote:
> Dear Peter,
> Le mer. 7 nov. 2018 ? 17:59, Peter Korsgaard <peter@korsgaard.com> a ?crit :
> >
> > >>>>> "Fabrice" == Fabrice Fontaine <fontaine.fabrice@gmail.com> writes:
> >
> > Hi,
> >
> > > 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
> > > BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_18 on a new
> > > BR2_PACKAGE_LIBV4L_KEYTABLE_BPF_PROTOCOLS option?
> >
> > 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.
> Thanks for your feedback, I will add a --without-libelf option to configure.ac.
No libelf is not enough for disabling bpf, see the autobuild failure [1]:
[...]
checking for LIBELF... no
configure: WARNING: libelf library not available
[...]
In file included from bpf.h:26:0,
from keytable.c:37:
../../include/linux/bpf.h:12:30: fatal error: linux/bpf_common.h: No such file or directory
#include <linux/bpf_common.h>
^
Maybe take a look at the upstream efforts:
[PATCH v2 v4l-utils] configure: build without BPF support in ir-keytable
https://patchwork.linuxtv.org/patch/52841/
Regards,
Peter
[1] http://autobuild.buildroot.org/results/d22c0939eed4bc949f7eaeae7595d01ec45cc2cd/build-end.log
> >
> > --
> > Bye, Peter Korsgaard
> Best Regards,
>
> Fabrice
prev parent reply other threads:[~2018-11-07 22:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-11-02 19:01 [Buildroot] [PATCH v1] libv4l: add missing bpf_common.h header Peter Seiderer
2018-11-03 13:28 ` Thomas Petazzoni
2018-11-05 20:59 ` Peter Seiderer
2018-11-06 20:01 ` Fabrice Fontaine
2018-11-06 22:32 ` Peter Seiderer
2018-11-07 16:59 ` Peter Korsgaard
2018-11-07 19:05 ` Fabrice Fontaine
2018-11-07 22:04 ` Peter Seiderer [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20181107230428.3a1e16fb@gmx.net \
--to=ps.report@gmx.net \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.