[meta-oe][PATCH v2] tcpreplay:add recipe

[meta-oe][PATCH v2] tcpreplay:add recipe

[b40527]

From: Zongchun Yu <Zongchun.Yu@freescale.com>

*tcpreplay - a suite of GPLv3 licensed tools for UNIX operating
systems which gives you the ability to use previously captured traffic
in libpcap format to test a variety of network devices.

Signed-off-by: Zongchun Yu <Zongchun.Yu@freescale.com>
---
 .../files/tcpreplay-3.4.4-cross-compile.patch      |   90 ++++++++++++++++++++
 .../files/tcpreplay-3.4.4-no-bfp-support.patch     |   13 +++
 .../recipes-support/tcpreplay/tcpreplay_3.4.4.bb   |   23 +++++
 3 files changed, 126 insertions(+)
 create mode 100755 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
 create mode 100644 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
 create mode 100644 meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb

diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
new file mode 100755
index 0000000..226f97a
--- /dev/null
+++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
@@ -0,0 +1,90 @@
+Uptream-Status: Inappropriate [embedded specific]
+
+--- a/configure.ac
++++ b/configure.ac
+@@ -402,7 +402,6 @@
+ 
+ dnl 0.9.6 (which is still thinks it is 0.9.5 due to a bug) introduces an important
+ dnl fix for OSX.  See: http://tcpreplay.synfin.net/trac/ticket/167
+-libpcap_version_096=no
+ AC_RUN_IFELSE(AC_LANG_PROGRAM([[
+ #include <string.h>
+ #include <stdlib.h>
+@@ -419,11 +418,12 @@
+             exit(0);
+ 
+     exit(1);
+-]]), [
+-    libpcap_version_096=yes
+-])
++]]),
++ [libpcap_version_096=yes],
++ [libpcap_version_096=no],
++ [libpcap_version_096=yes]
++)
+ 
+-libpcap_ver8=no
+ AC_RUN_IFELSE(AC_LANG_PROGRAM([[
+ #include <string.h>
+ #include <stdlib.h>
+@@ -444,13 +444,12 @@
+         exit(0);
+ 
+     exit(1);
+-]]), [
+-    libpcap_ver8=yes
+-], [
+-    libpcap_ver8=no
+-])
++]]),
++ [libpcap_ver8=yes],
++ [libpcap_ver8=no],
++ [libpcap_ver8=yes]
++)
+ 
+-libpcap_ver7=no
+ AC_RUN_IFELSE(AC_LANG_PROGRAM([[
+ #include <string.h>
+ #include <stdlib.h>
+@@ -469,11 +468,11 @@
+             exit(0);
+ 
+     exit(1);
+-]]), [
+-    libpcap_ver7=yes
+-], [
+-    libpcap_ver7=no
+-])
++]]),
++ [libpcap_ver7=yes],
++ [libpcap_ver7=no],
++ [libpcap_ver7=yes]
++)
+ 
+ if test x$libpcap_ver8 = xyes ; then
+     AC_MSG_RESULT(>= 0.8.0)
+@@ -761,8 +760,8 @@
+ 
+ have_bpf=no
+ dnl Check for BSD's BPF
+-AC_MSG_CHECKING(for BPF device sending support)
+-AC_TRY_RUN([
++AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
++[AC_TRY_RUN([
+ #include <stdio.h>
+ #include <stdlib.h>
+ #include <sys/types.h>
+@@ -796,8 +795,11 @@
+             [Do we have BPF device support?])
+     AC_MSG_RESULT(yes)
+     have_bpf=yes
+-],[
+-    AC_MSG_RESULT(no)
++],
++[AC_MSG_RESULT(no)],
++[AC_MSG_ERROR([cross-compiling,
++  presetting ac_cv_have_bpf=(yes|no) will help])]
++)
+ ])
+ 
+ 
diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
new file mode 100644
index 0000000..70fa959
--- /dev/null
+++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
@@ -0,0 +1,13 @@
+Uptream-Status: Inappropriate [embedded specific]
+
+--- a/configure.ac
++++ b/configure.ac
+@@ -758,6 +758,8 @@
+     AC_MSG_RESULT(no)
+ ])
+ 
++ac_cv_have_bpf=no
++
+ have_bpf=no
+ dnl Check for BSD's BPF
+ AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
diff --git a/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
new file mode 100644
index 0000000..98c9c4a
--- /dev/null
+++ b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
@@ -0,0 +1,23 @@
+SUMMARY = "Use previously captured traffic to test network devices"
+
+HOMEPAGE = "http://tcpreplay.synfin.net/"
+SECTION = "console/network"
+
+LICENSE = "GPLv3"
+LIC_FILES_CHKSUM = "file://docs/LICENSE;md5=c33cccf72cc1603e8a72a84811ae3ac8"
+
+PR = "r0"
+
+SRC_URI = "http://prdownloads.sourceforge.net/tcpreplay/${PV}/tcpreplay-${PV}.tar.gz \
+           file://tcpreplay-3.4.4-cross-compile.patch \
+           file://tcpreplay-3.4.4-no-bfp-support.patch \
+           "
+SRC_URI[md5sum] = "22725feb9b2590809f9350308ec65180"
+SRC_URI[sha256sum] = "7a809c58ddec86407fd6e5597ac883d7874a19bea81d716bb2b1c6e3b0e7b58f"
+
+DEPENDS = "libpcap"
+
+EXTRA_OECONF += "--with-libpcap=${STAGING_DIR_HOST}/usr"
+
+inherit siteinfo autotools
+
-- 
1.7.9.7

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 5430 bytes --]

On Thu, Oct 31, 2013 at 02:40:47AM -0500, b40527@freescale.com wrote:
> From: Zongchun Yu <Zongchun.Yu@freescale.com>
> 
> *tcpreplay - a suite of GPLv3 licensed tools for UNIX operating
> systems which gives you the ability to use previously captured traffic
> in libpcap format to test a variety of network devices.
> 
> Signed-off-by: Zongchun Yu <Zongchun.Yu@freescale.com>
> ---
>  .../files/tcpreplay-3.4.4-cross-compile.patch      |   90 ++++++++++++++++++++
>  .../files/tcpreplay-3.4.4-no-bfp-support.patch     |   13 +++
>  .../recipes-support/tcpreplay/tcpreplay_3.4.4.bb   |   23 +++++
>  3 files changed, 126 insertions(+)
>  create mode 100755 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
>  create mode 100644 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
>  create mode 100644 meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb

Looks like something for meta-networking?

> 
> diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
> new file mode 100755
> index 0000000..226f97a
> --- /dev/null
> +++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
> @@ -0,0 +1,90 @@
> +Uptream-Status: Inappropriate [embedded specific]
> +
> +--- a/configure.ac
> ++++ b/configure.ac
> +@@ -402,7 +402,6 @@
> + 
> + dnl 0.9.6 (which is still thinks it is 0.9.5 due to a bug) introduces an important
> + dnl fix for OSX.  See: http://tcpreplay.synfin.net/trac/ticket/167
> +-libpcap_version_096=no
> + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> + #include <string.h>
> + #include <stdlib.h>
> +@@ -419,11 +418,12 @@
> +             exit(0);
> + 
> +     exit(1);
> +-]]), [
> +-    libpcap_version_096=yes
> +-])
> ++]]),
> ++ [libpcap_version_096=yes],
> ++ [libpcap_version_096=no],
> ++ [libpcap_version_096=yes]
> ++)
> + 
> +-libpcap_ver8=no
> + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> + #include <string.h>
> + #include <stdlib.h>
> +@@ -444,13 +444,12 @@
> +         exit(0);
> + 
> +     exit(1);
> +-]]), [
> +-    libpcap_ver8=yes
> +-], [
> +-    libpcap_ver8=no
> +-])
> ++]]),
> ++ [libpcap_ver8=yes],
> ++ [libpcap_ver8=no],
> ++ [libpcap_ver8=yes]
> ++)
> + 
> +-libpcap_ver7=no
> + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> + #include <string.h>
> + #include <stdlib.h>
> +@@ -469,11 +468,11 @@
> +             exit(0);
> + 
> +     exit(1);
> +-]]), [
> +-    libpcap_ver7=yes
> +-], [
> +-    libpcap_ver7=no
> +-])
> ++]]),
> ++ [libpcap_ver7=yes],
> ++ [libpcap_ver7=no],
> ++ [libpcap_ver7=yes]
> ++)
> + 
> + if test x$libpcap_ver8 = xyes ; then
> +     AC_MSG_RESULT(>= 0.8.0)
> +@@ -761,8 +760,8 @@
> + 
> + have_bpf=no
> + dnl Check for BSD's BPF
> +-AC_MSG_CHECKING(for BPF device sending support)
> +-AC_TRY_RUN([
> ++AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
> ++[AC_TRY_RUN([
> + #include <stdio.h>
> + #include <stdlib.h>
> + #include <sys/types.h>
> +@@ -796,8 +795,11 @@
> +             [Do we have BPF device support?])
> +     AC_MSG_RESULT(yes)
> +     have_bpf=yes
> +-],[
> +-    AC_MSG_RESULT(no)
> ++],
> ++[AC_MSG_RESULT(no)],
> ++[AC_MSG_ERROR([cross-compiling,
> ++  presetting ac_cv_have_bpf=(yes|no) will help])]
> ++)
> + ])
> + 
> + 
> diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
> new file mode 100644
> index 0000000..70fa959
> --- /dev/null
> +++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
> @@ -0,0 +1,13 @@
> +Uptream-Status: Inappropriate [embedded specific]
> +
> +--- a/configure.ac
> ++++ b/configure.ac
> +@@ -758,6 +758,8 @@
> +     AC_MSG_RESULT(no)
> + ])
> + 
> ++ac_cv_have_bpf=no
> ++
> + have_bpf=no
> + dnl Check for BSD's BPF
> + AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
> diff --git a/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
> new file mode 100644
> index 0000000..98c9c4a
> --- /dev/null
> +++ b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
> @@ -0,0 +1,23 @@
> +SUMMARY = "Use previously captured traffic to test network devices"
> +
> +HOMEPAGE = "http://tcpreplay.synfin.net/"
> +SECTION = "console/network"
> +
> +LICENSE = "GPLv3"
> +LIC_FILES_CHKSUM = "file://docs/LICENSE;md5=c33cccf72cc1603e8a72a84811ae3ac8"
> +
> +PR = "r0"
> +
> +SRC_URI = "http://prdownloads.sourceforge.net/tcpreplay/${PV}/tcpreplay-${PV}.tar.gz \
> +           file://tcpreplay-3.4.4-cross-compile.patch \
> +           file://tcpreplay-3.4.4-no-bfp-support.patch \
> +           "
> +SRC_URI[md5sum] = "22725feb9b2590809f9350308ec65180"
> +SRC_URI[sha256sum] = "7a809c58ddec86407fd6e5597ac883d7874a19bea81d716bb2b1c6e3b0e7b58f"
> +
> +DEPENDS = "libpcap"
> +
> +EXTRA_OECONF += "--with-libpcap=${STAGING_DIR_HOST}/usr"
> +
> +inherit siteinfo autotools
> +
> -- 
> 1.7.9.7
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Zongchun YU]

Hi Martin.

Thanks for your kind comments. I see tcpdump in meta-oe layer too. tcpreplay
may use packages captured by tcpdump.
putting them in the same layer maybe better. Wish your suggestion?

Best Regards
Zongchun

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Thu, Oct 31, 2013 at 05:09:07PM +0800, Zongchun YU wrote:
> Hi Martin.
> 
> Thanks for your kind comments. I see tcpdump in meta-oe layer too. tcpreplay
> may use packages captured by tcpdump.
> putting them in the same layer maybe better. Wish your suggestion?
> 
> Best Regards
> Zongchun

+Joe

tcpdump is used only in one meta-oe recipe, were it can be dropped or
replaced with PACKAGECONFIG

meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb:    tcpdump

And then we can move tcpdump to meta-networking and add tcpreplay there.
-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 1454 bytes --]

[Re: [oe] [meta-oe][PATCH v2] tcpreplay:add recipe] On 13.10.31 (Thu 10:23) Martin Jansa wrote:

> On Thu, Oct 31, 2013 at 05:09:07PM +0800, Zongchun YU wrote:
> > Hi Martin.
> > 
> > Thanks for your kind comments. I see tcpdump in meta-oe layer too. tcpreplay
> > may use packages captured by tcpdump.
> > putting them in the same layer maybe better. Wish your suggestion?
> > 
> > Best Regards
> > Zongchun
> 
> +Joe
> 
> tcpdump is used only in one meta-oe recipe, were it can be dropped or
> replaced with PACKAGECONFIG
> 
> meta-oe/recipes-core/packagegroups/packagegroup-cli-tools.bb:    tcpdump
> 
> And then we can move tcpdump to meta-networking and add tcpreplay there.

Wow, been a while since I thought about tcpdump's location in the tree.
I knew we'd discussed moving it to meta-networking it previously and it
didn't move but I couldn't remember why.  Looks like it was mostly due
to inertia.  I've no objection to relocating it, I think it's a sensible
location for it anyway.  Zongchun:  would you be able to prepare a patch
set that includes the move and the introduction of tcpreplay?

As for the recipe itself, I only noticed two small things on a quick
scan.  tcpreplay-3.4.4-no-bfp-support.patch is lacking OE headers, at
least an upstream-status is important here, even though it's pretty
clear what that'll be.  :-)  Also, I don't think you need the PR in the
recipe.

-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Khem Raj]

On Thu, Oct 31, 2013 at 12:40 AM,  <b40527@freescale.com> wrote:
> +PR = "r0"

get rid of that, and why are the configure patches not ok for upstreaming ?

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Zongchun YU]

>get rid of that, and why are the configure patches not ok for upstreaming ?

Hello Khem.

Thanks for your comments, I am a newcomer for upstreaming. Do you mean that first I should send the two patches
to upstream?

Best Regards
Zongchun
-----邮件原件-----
发件人: Khem Raj [mailto:raj.khem@gmail.com] 
发送时间: 2013年11月1日 0:36
收件人: openembeded-devel
抄送: Zongchun Yu; b44149@freescale.com
主题: Re: [oe] [meta-oe][PATCH v2] tcpreplay:add recipe

On Thu, Oct 31, 2013 at 12:40 AM,  <b40527@freescale.com> wrote:
> +PR = "r0"

get rid of that, and why are the configure patches not ok for upstreaming ?

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Zongchun YU]

>Wow, been a while since I thought about tcpdump's location in the tree.
>I knew we'd discussed moving it to meta-networking it previously and it
didn't move but I couldn't remember why.  Looks like it was mostly due to
inertia.  I've no objection to relocating it, I think it's a sensible
location for it anyway.  Zongchun:  would you be able to prepare a patch set
that includes the move and the introduction of tcpreplay?

>As for the recipe itself, I only noticed two small things on a quick scan.
tcpreplay-3.4.4-no-bfp-support.patch is lacking OE headers, at least an
upstream-status is important here, even though it's pretty clear what
that'll be.  :-)  Also, I don't think you need the PR in the recipe.

Joe: Thanks for your comments. I will prepare the patch set.

Re: [meta-oe][PATCH] tcpreplay:add recipe

[Khem Raj]

On Thursday, October 31, 2013, Zongchun YU wrote:

> >get rid of that, and why are the configure patches not ok for upstreaming
> ?
>
> Hello Khem.
>
> Thanks for your comments, I am a newcomer for upstreaming. Do you mean
> that first I should send the two patches
> to upstream?



They were marked inappropriate for up streaming, that's what my question
was about

>
> Best Regards
> Zongchun
> -----邮件原件-----
> 发件人: Khem Raj [mailto:raj.khem@gmail.com <javascript:;>]
> 发送时间: 2013年11月1日 0:36
> 收件人: openembeded-devel
> 抄送: Zongchun Yu; b44149@freescale.com <javascript:;>
> 主题: Re: [oe] [meta-oe][PATCH v2] tcpreplay:add recipe
>
> On Thu, Oct 31, 2013 at 12:40 AM,  <b40527@freescale.com <javascript:;>>
> wrote:
> > +PR = "r0"
>
> get rid of that, and why are the configure patches not ok for upstreaming ?
>
>
>

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[w201cruiser .]

Boah Leute könnt ihr mal aufhören mein Postfach zuzumüllen?!


2013/11/1 Zongchun YU <b40527@freescale.com>

> >get rid of that, and why are the configure patches not ok for upstreaming
> ?
>
> Hello Khem.
>
> Thanks for your comments, I am a newcomer for upstreaming. Do you mean
> that first I should send the two patches
> to upstream?
>
> Best Regards
> Zongchun
> -----邮件原件-----
> 发件人: Khem Raj [mailto:raj.khem@gmail.com]
> 发送时间: 2013年11月1日 0:36
> 收件人: openembeded-devel
> 抄送: Zongchun Yu; b44149@freescale.com
> 主题: Re: [oe] [meta-oe][PATCH v2] tcpreplay:add recipe
>
> On Thu, Oct 31, 2013 at 12:40 AM,  <b40527@freescale.com> wrote:
> > +PR = "r0"
>
> get rid of that, and why are the configure patches not ok for upstreaming ?
>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 9576 bytes --]

On Thu, Oct 31, 2013 at 09:10:12AM +0100, Martin Jansa wrote:
> On Thu, Oct 31, 2013 at 02:40:47AM -0500, b40527@freescale.com wrote:
> > From: Zongchun Yu <Zongchun.Yu@freescale.com>
> > 
> > *tcpreplay - a suite of GPLv3 licensed tools for UNIX operating
> > systems which gives you the ability to use previously captured traffic
> > in libpcap format to test a variety of network devices.
> > 
> > Signed-off-by: Zongchun Yu <Zongchun.Yu@freescale.com>
> > ---
> >  .../files/tcpreplay-3.4.4-cross-compile.patch      |   90 ++++++++++++++++++++
> >  .../files/tcpreplay-3.4.4-no-bfp-support.patch     |   13 +++
> >  .../recipes-support/tcpreplay/tcpreplay_3.4.4.bb   |   23 +++++
> >  3 files changed, 126 insertions(+)
> >  create mode 100755 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
> >  create mode 100644 meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
> >  create mode 100644 meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
> 
> Looks like something for meta-networking?

it fails to detect libpcap in my world builds:

| checking for libpcap... /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr
| checking for library containing pcap_close... no
| configure: error: Unable to link libpcap in /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr
| Configure failed. The contents of all config.log files follows to aid debugging
| /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/work/armv5te-oe-linux-gnueabi/tcpreplay/3.4.4-r0/tcpreplay-3.4.4/config.log
| This file contains any messages produced by compilers while
| running configure, to aid debugging if configure makes a mistake.

| configure:18128: checking for libpcap
| configure:18170: result: /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr
| configure:18180: checking for library containing pcap_close
| configure:18211: arm-oe-linux-gnueabi-gcc  -march=armv5te -marm -mthumb-interwork --sysroot=/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm -o conftest -D_U_="__attribute__((unused))" -O2 -pipe -g -feliminate-unused-debug-types -Wall -O3 -std=gnu99 -Wextra -Wno-variadic-macros -Wfatal-errors -I/home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr/include  -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c /home/jenkins/oe/shr-core-branches/shr-core/tmp-eglibc/sysroots/qemuarm/usr/lib/libpcap.a >&5
| ./pcap-linux.c:525: error: undefined reference to 'nl_socket_alloc'
| ./pcap-linux.c:532: error: undefined reference to 'genl_connect'
| ./pcap-linux.c:538: error: undefined reference to 'genl_ctrl_alloc_cache'
| ./pcap-linux.c:546: error: undefined reference to 'genl_ctrl_search_by_name'
| ./pcap-linux.c:558: error: undefined reference to 'nl_socket_free'
| ./pcap-linux.c:540: error: undefined reference to 'nl_geterror'
| ./pcap-linux.c:556: error: undefined reference to 'nl_cache_free'
| ./pcap-linux.c:565: error: undefined reference to 'genl_family_put'
| ./pcap-linux.c:566: error: undefined reference to 'nl_cache_free'
| ./pcap-linux.c:567: error: undefined reference to 'nl_socket_free'
| ./pcap-linux.c:678: error: undefined reference to 'nlmsg_alloc'
| ./pcap-linux.c:685: error: undefined reference to 'genl_family_get_id'
| ./pcap-linux.c:685: error: undefined reference to 'genlmsg_put'
| ./pcap-linux.c:687: error: undefined reference to 'nla_put'
| ./pcap-linux.c:689: error: undefined reference to 'nl_send_auto_complete'
| ./pcap-linux.c:697: error: undefined reference to 'nl_wait_for_ack'
| ./pcap-linux.c:709: error: undefined reference to 'nlmsg_free'
| ./pcap-linux.c:716: error: undefined reference to 'nlmsg_free'
| ./pcap-linux.c:691: error: undefined reference to 'nl_geterror'
| ./pcap-linux.c:702: error: undefined reference to 'nlmsg_free'
| ./pcap-linux.c:699: error: undefined reference to 'nl_geterror'
| ./pcap-linux.c:582: error: undefined reference to 'nlmsg_alloc'
| ./pcap-linux.c:589: error: undefined reference to 'genl_family_get_id'
| ./pcap-linux.c:589: error: undefined reference to 'genlmsg_put'
| ./pcap-linux.c:591: error: undefined reference to 'nla_put'
| ./pcap-linux.c:592: error: undefined reference to 'nla_put'
| ./pcap-linux.c:593: error: undefined reference to 'nla_put'
| ./pcap-linux.c:595: error: undefined reference to 'nl_send_auto_complete'
| ./pcap-linux.c:623: error: undefined reference to 'nl_wait_for_ack'
| ./pcap-linux.c:637: error: undefined reference to 'nlmsg_free'
| ./pcap-linux.c:616: error: undefined reference to 'nl_geterror'
| collect2: error: ld returned 1 exit status
| configure:18211: $? = 1



> 
> > 
> > diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
> > new file mode 100755
> > index 0000000..226f97a
> > --- /dev/null
> > +++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-cross-compile.patch
> > @@ -0,0 +1,90 @@
> > +Uptream-Status: Inappropriate [embedded specific]
> > +
> > +--- a/configure.ac
> > ++++ b/configure.ac
> > +@@ -402,7 +402,6 @@
> > + 
> > + dnl 0.9.6 (which is still thinks it is 0.9.5 due to a bug) introduces an important
> > + dnl fix for OSX.  See: http://tcpreplay.synfin.net/trac/ticket/167
> > +-libpcap_version_096=no
> > + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> > + #include <string.h>
> > + #include <stdlib.h>
> > +@@ -419,11 +418,12 @@
> > +             exit(0);
> > + 
> > +     exit(1);
> > +-]]), [
> > +-    libpcap_version_096=yes
> > +-])
> > ++]]),
> > ++ [libpcap_version_096=yes],
> > ++ [libpcap_version_096=no],
> > ++ [libpcap_version_096=yes]
> > ++)
> > + 
> > +-libpcap_ver8=no
> > + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> > + #include <string.h>
> > + #include <stdlib.h>
> > +@@ -444,13 +444,12 @@
> > +         exit(0);
> > + 
> > +     exit(1);
> > +-]]), [
> > +-    libpcap_ver8=yes
> > +-], [
> > +-    libpcap_ver8=no
> > +-])
> > ++]]),
> > ++ [libpcap_ver8=yes],
> > ++ [libpcap_ver8=no],
> > ++ [libpcap_ver8=yes]
> > ++)
> > + 
> > +-libpcap_ver7=no
> > + AC_RUN_IFELSE(AC_LANG_PROGRAM([[
> > + #include <string.h>
> > + #include <stdlib.h>
> > +@@ -469,11 +468,11 @@
> > +             exit(0);
> > + 
> > +     exit(1);
> > +-]]), [
> > +-    libpcap_ver7=yes
> > +-], [
> > +-    libpcap_ver7=no
> > +-])
> > ++]]),
> > ++ [libpcap_ver7=yes],
> > ++ [libpcap_ver7=no],
> > ++ [libpcap_ver7=yes]
> > ++)
> > + 
> > + if test x$libpcap_ver8 = xyes ; then
> > +     AC_MSG_RESULT(>= 0.8.0)
> > +@@ -761,8 +760,8 @@
> > + 
> > + have_bpf=no
> > + dnl Check for BSD's BPF
> > +-AC_MSG_CHECKING(for BPF device sending support)
> > +-AC_TRY_RUN([
> > ++AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
> > ++[AC_TRY_RUN([
> > + #include <stdio.h>
> > + #include <stdlib.h>
> > + #include <sys/types.h>
> > +@@ -796,8 +795,11 @@
> > +             [Do we have BPF device support?])
> > +     AC_MSG_RESULT(yes)
> > +     have_bpf=yes
> > +-],[
> > +-    AC_MSG_RESULT(no)
> > ++],
> > ++[AC_MSG_RESULT(no)],
> > ++[AC_MSG_ERROR([cross-compiling,
> > ++  presetting ac_cv_have_bpf=(yes|no) will help])]
> > ++)
> > + ])
> > + 
> > + 
> > diff --git a/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
> > new file mode 100644
> > index 0000000..70fa959
> > --- /dev/null
> > +++ b/meta-oe/recipes-support/tcpreplay/files/tcpreplay-3.4.4-no-bfp-support.patch
> > @@ -0,0 +1,13 @@
> > +Uptream-Status: Inappropriate [embedded specific]
> > +
> > +--- a/configure.ac
> > ++++ b/configure.ac
> > +@@ -758,6 +758,8 @@
> > +     AC_MSG_RESULT(no)
> > + ])
> > + 
> > ++ac_cv_have_bpf=no
> > ++
> > + have_bpf=no
> > + dnl Check for BSD's BPF
> > + AC_CACHE_CHECK([for BPF device sending support], ac_cv_have_bpf,
> > diff --git a/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
> > new file mode 100644
> > index 0000000..98c9c4a
> > --- /dev/null
> > +++ b/meta-oe/recipes-support/tcpreplay/tcpreplay_3.4.4.bb
> > @@ -0,0 +1,23 @@
> > +SUMMARY = "Use previously captured traffic to test network devices"
> > +
> > +HOMEPAGE = "http://tcpreplay.synfin.net/"
> > +SECTION = "console/network"
> > +
> > +LICENSE = "GPLv3"
> > +LIC_FILES_CHKSUM = "file://docs/LICENSE;md5=c33cccf72cc1603e8a72a84811ae3ac8"
> > +
> > +PR = "r0"
> > +
> > +SRC_URI = "http://prdownloads.sourceforge.net/tcpreplay/${PV}/tcpreplay-${PV}.tar.gz \
> > +           file://tcpreplay-3.4.4-cross-compile.patch \
> > +           file://tcpreplay-3.4.4-no-bfp-support.patch \
> > +           "
> > +SRC_URI[md5sum] = "22725feb9b2590809f9350308ec65180"
> > +SRC_URI[sha256sum] = "7a809c58ddec86407fd6e5597ac883d7874a19bea81d716bb2b1c6e3b0e7b58f"
> > +
> > +DEPENDS = "libpcap"
> > +
> > +EXTRA_OECONF += "--with-libpcap=${STAGING_DIR_HOST}/usr"
> > +
> > +inherit siteinfo autotools
> > +
> > -- 
> > 1.7.9.7
> > 
> > 
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com



-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [meta-oe][PATCH v2] tcpreplay:add recipe

[Zongchun YU]

>it fails to detect libpcap in my world builds:

Thanks for your feedback. I am investigating this issue. It will be fixed in
the latest patches.