Signed-off-by: Julian Ospald hasufell@posteo.de --- configure.ac | 17 ++++++++++++++--- 1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/configure.ac b/configure.ac index e5503f1..a69e2dd 100644 --- a/configure.ac +++ b/configure.ac @@ -331,9 +331,20 @@ else fi AC_SUBST([argp_LDADD])
-dnl Check if we have <linux/bpf.h> for EM_BPF disassembly. -AC_CHECK_HEADERS(linux/bpf.h) -AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "x$ac_cv_header_linux_bpf_h" = "xyes"]) +dnl Check if we have <linux/bpf.h> for EM_BPF disassembly and it has the required defines +AC_COMPILE_IFELSE( + [AC_LANG_PROGRAM( + [#include <linux/bpf.h>], + [int foo=BPF_PSEUDO_MAP_FD; return 0;] + )], + [have_bpf="true"], + [have_bpf="false"] +) + +if test "$have_bpf" = "true" ; then + AC_DEFINE([HAVE_LINUX_BPF_H], [1], [if we have <linux/bpf.h> for EM_BPF disassembly]) +fi +AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "$have_bpf" = "true"])
dnl The directories with content.
On Tue, 2016-08-30 at 23:38 +0200, Julian Ospald wrote:
-dnl Check if we have <linux/bpf.h> for EM_BPF disassembly. -AC_CHECK_HEADERS(linux/bpf.h) -AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "x$ac_cv_header_linux_bpf_h" = "xyes"]) +dnl Check if we have <linux/bpf.h> for EM_BPF disassembly and it has the required defines +AC_COMPILE_IFELSE(
- [AC_LANG_PROGRAM(
[#include <linux/bpf.h>],
[int foo=BPF_PSEUDO_MAP_FD; return 0;]
)],
- [have_bpf="true"],
- [have_bpf="false"]
+)
+if test "$have_bpf" = "true" ; then
- AC_DEFINE([HAVE_LINUX_BPF_H], [1], [if we have <linux/bpf.h> for EM_BPF disassembly])
+fi +AM_CONDITIONAL(HAVE_LINUX_BPF_H, [test "$have_bpf" = "true"])
Thanks, that does look like the correct configure check.
But it seems that BPF_PSEUDO_MAP_FD is the only missing constant introduced since 3.18 (when linux/bpf.h was added) that we use. So maybe we could simply define it ourselves when not found. So we can build against any linux/bpf.h out there.
What do people think of the following?
diff --git a/libcpu/bpf_disasm.c b/libcpu/bpf_disasm.c index 153dba9..e4bbae4 100644 --- a/libcpu/bpf_disasm.c +++ b/libcpu/bpf_disasm.c @@ -40,6 +40,10 @@ #include "../libelf/common.h" #include "../libebl/libeblP.h"
+/* BPF_PSEUDO_MAP_FD was only introduced in linux 3.20. */ +#ifndef BPF_PSEUDO_MAP_FD + #define BPF_PSEUDO_MAP_FD 1 +#endif
static const char class_string[8][8] = { [BPF_LD] = "ld",
Thanks,
Mark
On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
Thanks, that does look like the correct configure check.
But it seems that BPF_PSEUDO_MAP_FD is the only missing constant introduced since 3.18 (when linux/bpf.h was added) that we use. So maybe we could simply define it ourselves when not found. So we can build against any linux/bpf.h out there.
What do people think of the following?
I tested it against the latest stable kernel and headers from the 3.18 kernel and it seems to work fine. Any objections to commit the attached?
Thanks,
Mark
On 09/05/2016 02:21 AM, Mark Wielaard wrote:
On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
Thanks, that does look like the correct configure check.
But it seems that BPF_PSEUDO_MAP_FD is the only missing constant introduced since 3.18 (when linux/bpf.h was added) that we use. So maybe we could simply define it ourselves when not found. So we can build against any linux/bpf.h out there.
What do people think of the following?
I tested it against the latest stable kernel and headers from the 3.18 kernel and it seems to work fine. Any objections to commit the attached?
None.
r~
On Tue, 2016-09-06 at 10:00 -0700, Richard Henderson wrote:
On 09/05/2016 02:21 AM, Mark Wielaard wrote:
On Wed, 2016-08-31 at 16:21 +0200, Mark Wielaard wrote:
Thanks, that does look like the correct configure check.
But it seems that BPF_PSEUDO_MAP_FD is the only missing constant introduced since 3.18 (when linux/bpf.h was added) that we use. So maybe we could simply define it ourselves when not found. So we can build against any linux/bpf.h out there.
What do people think of the following?
I tested it against the latest stable kernel and headers from the 3.18 kernel and it seems to work fine. Any objections to commit the attached?
None.
Thanks. Pushed to master.
elfutils-devel@lists.fedorahosted.org