From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <luca.boccassi@gmail.com>
Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com
[209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 48E573798
for <dev@dpdk.org>; Thu, 4 Apr 2019 10:39:09 +0200 (CEST)
Received: by mail-wr1-f68.google.com with SMTP id s15so2554922wra.12
for <dev@dpdk.org>; Thu, 04 Apr 2019 01:39:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to
:references:content-transfer-encoding:user-agent:mime-version;
bh=7uPYICLRkNOxmvNasbLjoZ04l7fI/Y69lF+3FG/1AeI=;
b=XkBwACFlPwPGmI1Per07EBwekbvFeHcCkl+nAs46t6nhHGwRpre5raX7ER9uhrUlpk
n6q0ZtYbqqTnYxfmjPe9L5VfXMzMxv2keexX1alYD9EpGcQXLGOfdLHwv9q6o7dpLRhR
GY1U7Ho+4eAU+HQfEn37AxsRj9c1OBL4QKZEydr1AcCYSndbX2j3sOxEBCiqIfN1Nia0
SF2lfFkKTU+c4DmK1l9zuf4tg4yL3XF3sOH7EcnAdxTo7NfoEKHs74sredYMspgj2wAm
vuCO/XfMx3gguVttbdAZdoDJTH6pr1fk9jCHb27G8IFagGru0k9jqXoOpWk9Mv0PVYOu
LT/g==
X-Gm-Message-State: APjAAAWTaLEuyhYqBdlu7YRDZGg4yJRhChSEJ/GwND8VbcUI1qWT/1jk
mhHBY/0r1px0i9KBNuKQT2c=
X-Google-Smtp-Source: APXvYqwI4tQlFfxluOUTyzRyObqqnK0gW2QnobVziGHFGpHRC/rTF9cWwsxxCK8mAB/7fmlBAJ9j+g==
X-Received: by 2002:adf:ee0e:: with SMTP id y14mr583193wrn.21.1554367148774;
Thu, 04 Apr 2019 01:39:08 -0700 (PDT)
Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60])
by smtp.gmail.com with ESMTPSA id g84sm27939227wmf.25.2019.04.04.01.39.06
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 04 Apr 2019 01:39:06 -0700 (PDT)
Message-ID: <a5dd7312ed008d84e0f60cfb89c6f88dc8f3141b.camel@debian.org>
From: Luca Boccassi <bluca@debian.org>
To: Ye Xiaolong <xiaolong.ye@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>, Qi Zhang
<qi.z.zhang@intel.com>, Karlsson Magnus <magnus.karlsson@intel.com>, Topel
Bjorn <bjorn.topel@intel.com>, Maxime Coquelin
<maxime.coquelin@redhat.com>, Bruce Richardson
<bruce.richardson@intel.com>, Ananyev Konstantin
<konstantin.ananyev@intel.com>, David Marchand
<david.marchand@redhat.com>, Andrew Rybchenko <arybchenko@solarflare.com>,
Olivier Matz <olivier.matz@6wind.com>
Date: Thu, 04 Apr 2019 09:39:05 +0100
In-Reply-To: <20190404055515.GB45121@intel.com>
References: <20190301080947.91086-1-xiaolong.ye@intel.com>
<20190403165949.44857-1-xiaolong.ye@intel.com>
<20190403165949.44857-2-xiaolong.ye@intel.com>
<25be95ff-132c-9e3e-fe3d-b5aac3dfb388@intel.com>
<181fca1e5a2274ad2e7638c25b459ab7f426f254.camel@debian.org>
<20190404055515.GB45121@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.30.5-1
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v10 1/1] net/af_xdp: introduce AF XDP PMD
driver
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Apr 2019 08:39:09 -0000
On Thu, 2019-04-04 at 13:55 +0800, Ye Xiaolong wrote:
> Hi, Luca
>=20
> On 04/03, Luca Boccassi wrote:
> > On Wed, 2019-04-03 at 18:44 +0100, Ferruh Yigit wrote:
> > > On 4/3/2019 5:59 PM, Xiaolong Ye wrote:
> > > > Add a new PMD driver for AF_XDP which is a proposed faster
> > > > version
> > > > of
> > > > AF_PACKET interface in Linux. More info about AF_XDP, please
> > > > refer
> > > > to [1]
> > > > [2].
> > > >=20
> > > > This is the vanilla version PMD which just uses a raw buffer
> > > > registered as
> > > > the umem.
> > > >=20
> > > > [1]=20
> > > > https://fosdem.org/2018/schedule/event/af_xdp/
> > > >=20
> > > >=20
> > > > [2]=20
> > > > https://lwn.net/Articles/745934/
> > > >=20
> > > >=20
> > > >=20
> > > > Signed-off-by: Xiaolong Ye <
> > > > xiaolong.ye@intel.com
> > > >=20
> > >=20
> > > I am not able to test functionality but code looks good to me, I
> > > can
> > > compile via
> > > Makefile (with suggested steps in doc) but not able to build with
> > > meson, can you
> > > please check below comments?
> > >=20
> > > <...>
> > >=20
> > > > @@ -0,0 +1,21 @@
> > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > +# Copyright(c) 2019 Intel Corporation
> > > > +
> > > > +if host_machine.system() !=3D 'linux'
> > > > + build =3D false
> > > > +endif
> > >=20
> > > After this point, if build is false it shouldn't continue to
> > > below
> > > checks I think.
> > >=20
> > > > +
> > > > +bpf_dep =3D dependency('libbpf', required: false)
> > >=20
> > > My library is in '/usr/local/lib64/libbpf.so' but this line can't
> > > find it. Where
> > > does 'dependency()' checks for libraries?
> >=20
> > dependency() uses only pkg-config (or cmake or embedded specific
> > tools,
> > neither of which applies to bpf), so if you haven't built from bpf-
> > next=20
> > you won't have the pkg-config file installed, and it will fall back
> > to
> > the next block.
> >=20
> > Side note, there's an issue open upstream in Meson to merge
> > dependency() and find_library(), with some traction but it's not
> > done
> > yet.
> >=20
> > For me building from bpf-next it works fine:
> >=20
> > $ PKG_CONFIG_PATH=3D/tmp/bpf/lib64/pkgconfig/ ninja -C build-gcc-
> > shared
> > ...
> > Dependency libbpf found: YES 0.0.2
> > ...
> > $ lddtree build-gcc-shared/drivers/librte_pmd_af_xdp.so.1.1=20
> > librte_pmd_af_xdp.so.1.1 =3D> build-gcc-
> > shared/drivers/librte_pmd_af_xdp.so.1.1 (interpreter =3D> none)
> > libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6
> > libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2
> > libnuma.so.1 =3D> /lib/x86_64-linux-gnu/libnuma.so.1
> > librte_ethdev.so.12 =3D> build-gcc-
> > shared/drivers/../lib/librte_ethdev.so.12
> > librte_eal.so.10 =3D> build-gcc-
> > shared/drivers/../lib/librte_eal.so.10
> > librte_kvargs.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_kvargs.so.1
> > librte_net.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_net.so.1
> > librte_mbuf.so.5 =3D> build-gcc-
> > shared/drivers/../lib/librte_mbuf.so.5
> > librte_mempool.so.5 =3D> build-gcc-
> > shared/drivers/../lib/librte_mempool.so.5
> > librte_ring.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_ring.so.2
> > librte_cmdline.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_cmdline.so.2
> > librte_meter.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_meter.so.2
> > librte_bus_pci.so.2 =3D> not found
> > librte_pci.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_pci.so.1
> > librte_bus_vdev.so.2 =3D> not found
> > libbsd.so.0 =3D> /lib/x86_64-linux-gnu/libbsd.so.0
> > librt.so.1 =3D> /lib/x86_64-linux-gnu/librt.so.1
> > libbpf.so.0 =3D> /tmp/bpf/lib64/libbpf.so.0
> > libelf.so.1 =3D> /lib/x86_64-linux-gnu/libelf.so.1
> > libz.so.1 =3D> /lib/x86_64-linux-gnu/libz.so.1
> > libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0
> > libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6
> > ld-linux-x86-64.so.2 =3D> /lib/x86_64-linux-gnu/ld-linux-x86-
> > 64.so.2
> >=20
> > > > +if bpf_dep.found()
> > > > + build =3D true
> > > > +else
> > > > + bpf_dep =3D cc.find_library('libbpf', required: false)
> > >=20
> > > Also this line can't find it, in log it says "(tried pkgconfig
> > > and
> > > cmake)" and
> > > yes there is no pkgconfig for it, any idea how 'cmake' used?
> >=20
> > The issue here is that it should be cc.find_library('bpf' - not
> > 'libbpf'. I missed this when reviewing, good catch.
> >=20
> > That's because find_library just does a compilation test passing
> > the
> > value to the compiler as a linker flag - so right now it's passing
> > -llibbpf. Fixing this line and the header line below makes it work
> > without pkg-config:
> >=20
> > $ CPPFLAGS=3D-I/tmp/bpf/include LDFLAGS=3D-L/tmp/bpf/lib64 meson testt
> > ...
> > Dependency libbpf found: NO (tried pkgconfig and cmake)
> > Library bpf found: YES
>=20
> After apply the fix in af_xdp pmd's meson.build, now I was able to
> build
> library for af_xdp pmd.
>=20
> $ ls drivers/ |grep xdp
> a715181@@rte_pmd_af_xdp@sha
> a715181@@rte_pmd_af_xdp@sta
> a715181@@tmp_rte_pmd_af_xdp@sta
> librte_pmd_af_xdp.a
> librte_pmd_af_xdp.so
> librte_pmd_af_xdp.so.1
> librte_pmd_af_xdp.so.1.1
> libtmp_rte_pmd_af_xdp.a
> rte_pmd_af_xdp.pmd.c
>=20
> But I found that if I install libbpf to /usr/local/lib64 by default,
> application
> built by meson build will fail to run:
>=20
> $ ./dpdk-testpmd
> ./dpdk-testpmd: error while loading shared libraries: libbpf.so.0:
> cannot open shared object file: No such file or directory
>=20
> While install libbpf to /usr/lib doesn't have this issue (I was
> testing on ubuntu system).
> Is it a expected behavior? Do we need any fix for it?
Hi,
That is expected and distro specific: if your distro doesn't add
/usr/local/lib* to the compiler path, it also won't be in the
LD_LIBRARY_PATH.
So if you do:
LD_LIBRARY_PATH=3D/usr/local/lib64 ./dpdk-testpmd
It should then work. It's not related to the build system, but just to
what the default paths are in the distro.
--=20
Kind regards,
Luca Boccassi
From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
Received: from dpdk.org (dpdk.org [92.243.14.124])
by dpdk.space (Postfix) with ESMTP id 66660A0679
for <public@inbox.dpdk.org>; Thu, 4 Apr 2019 10:39:12 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
by dpdk.org (Postfix) with ESMTP id 2A2154F98;
Thu, 4 Apr 2019 10:39:11 +0200 (CEST)
Received: from mail-wr1-f68.google.com (mail-wr1-f68.google.com
[209.85.221.68]) by dpdk.org (Postfix) with ESMTP id 48E573798
for <dev@dpdk.org>; Thu, 4 Apr 2019 10:39:09 +0200 (CEST)
Received: by mail-wr1-f68.google.com with SMTP id s15so2554922wra.12
for <dev@dpdk.org>; Thu, 04 Apr 2019 01:39:09 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to
:references:content-transfer-encoding:user-agent:mime-version;
bh=7uPYICLRkNOxmvNasbLjoZ04l7fI/Y69lF+3FG/1AeI=;
b=XkBwACFlPwPGmI1Per07EBwekbvFeHcCkl+nAs46t6nhHGwRpre5raX7ER9uhrUlpk
n6q0ZtYbqqTnYxfmjPe9L5VfXMzMxv2keexX1alYD9EpGcQXLGOfdLHwv9q6o7dpLRhR
GY1U7Ho+4eAU+HQfEn37AxsRj9c1OBL4QKZEydr1AcCYSndbX2j3sOxEBCiqIfN1Nia0
SF2lfFkKTU+c4DmK1l9zuf4tg4yL3XF3sOH7EcnAdxTo7NfoEKHs74sredYMspgj2wAm
vuCO/XfMx3gguVttbdAZdoDJTH6pr1fk9jCHb27G8IFagGru0k9jqXoOpWk9Mv0PVYOu
LT/g==
X-Gm-Message-State: APjAAAWTaLEuyhYqBdlu7YRDZGg4yJRhChSEJ/GwND8VbcUI1qWT/1jk
mhHBY/0r1px0i9KBNuKQT2c=
X-Google-Smtp-Source: APXvYqwI4tQlFfxluOUTyzRyObqqnK0gW2QnobVziGHFGpHRC/rTF9cWwsxxCK8mAB/7fmlBAJ9j+g==
X-Received: by 2002:adf:ee0e:: with SMTP id y14mr583193wrn.21.1554367148774;
Thu, 04 Apr 2019 01:39:08 -0700 (PDT)
Received: from localhost ([2a01:4b00:f419:6f00:250:b6ff:feb7:bd60])
by smtp.gmail.com with ESMTPSA id g84sm27939227wmf.25.2019.04.04.01.39.06
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
Thu, 04 Apr 2019 01:39:06 -0700 (PDT)
Message-ID: <a5dd7312ed008d84e0f60cfb89c6f88dc8f3141b.camel@debian.org>
From: Luca Boccassi <bluca@debian.org>
To: Ye Xiaolong <xiaolong.ye@intel.com>, Ferruh Yigit <ferruh.yigit@intel.com>
Cc: dev@dpdk.org, Stephen Hemminger <stephen@networkplumber.org>, Qi Zhang
<qi.z.zhang@intel.com>, Karlsson Magnus <magnus.karlsson@intel.com>, Topel
Bjorn <bjorn.topel@intel.com>, Maxime Coquelin
<maxime.coquelin@redhat.com>, Bruce Richardson
<bruce.richardson@intel.com>, Ananyev Konstantin
<konstantin.ananyev@intel.com>, David Marchand
<david.marchand@redhat.com>, Andrew Rybchenko <arybchenko@solarflare.com>,
Olivier Matz <olivier.matz@6wind.com>
Date: Thu, 04 Apr 2019 09:39:05 +0100
In-Reply-To: <20190404055515.GB45121@intel.com>
References: <20190301080947.91086-1-xiaolong.ye@intel.com>
<20190403165949.44857-1-xiaolong.ye@intel.com>
<20190403165949.44857-2-xiaolong.ye@intel.com>
<25be95ff-132c-9e3e-fe3d-b5aac3dfb388@intel.com>
<181fca1e5a2274ad2e7638c25b459ab7f426f254.camel@debian.org>
<20190404055515.GB45121@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.30.5-1
MIME-Version: 1.0
Subject: Re: [dpdk-dev] [PATCH v10 1/1] net/af_xdp: introduce AF XDP PMD
driver
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>
Message-ID: <20190404083905.gHCjtoOLQGrcj7OzINlo99FcEW3Et1e_R8QPGAGdx8I@z>
On Thu, 2019-04-04 at 13:55 +0800, Ye Xiaolong wrote:
> Hi, Luca
>=20
> On 04/03, Luca Boccassi wrote:
> > On Wed, 2019-04-03 at 18:44 +0100, Ferruh Yigit wrote:
> > > On 4/3/2019 5:59 PM, Xiaolong Ye wrote:
> > > > Add a new PMD driver for AF_XDP which is a proposed faster
> > > > version
> > > > of
> > > > AF_PACKET interface in Linux. More info about AF_XDP, please
> > > > refer
> > > > to [1]
> > > > [2].
> > > >=20
> > > > This is the vanilla version PMD which just uses a raw buffer
> > > > registered as
> > > > the umem.
> > > >=20
> > > > [1]=20
> > > > https://fosdem.org/2018/schedule/event/af_xdp/
> > > >=20
> > > >=20
> > > > [2]=20
> > > > https://lwn.net/Articles/745934/
> > > >=20
> > > >=20
> > > >=20
> > > > Signed-off-by: Xiaolong Ye <
> > > > xiaolong.ye@intel.com
> > > >=20
> > >=20
> > > I am not able to test functionality but code looks good to me, I
> > > can
> > > compile via
> > > Makefile (with suggested steps in doc) but not able to build with
> > > meson, can you
> > > please check below comments?
> > >=20
> > > <...>
> > >=20
> > > > @@ -0,0 +1,21 @@
> > > > +# SPDX-License-Identifier: BSD-3-Clause
> > > > +# Copyright(c) 2019 Intel Corporation
> > > > +
> > > > +if host_machine.system() !=3D 'linux'
> > > > + build =3D false
> > > > +endif
> > >=20
> > > After this point, if build is false it shouldn't continue to
> > > below
> > > checks I think.
> > >=20
> > > > +
> > > > +bpf_dep =3D dependency('libbpf', required: false)
> > >=20
> > > My library is in '/usr/local/lib64/libbpf.so' but this line can't
> > > find it. Where
> > > does 'dependency()' checks for libraries?
> >=20
> > dependency() uses only pkg-config (or cmake or embedded specific
> > tools,
> > neither of which applies to bpf), so if you haven't built from bpf-
> > next=20
> > you won't have the pkg-config file installed, and it will fall back
> > to
> > the next block.
> >=20
> > Side note, there's an issue open upstream in Meson to merge
> > dependency() and find_library(), with some traction but it's not
> > done
> > yet.
> >=20
> > For me building from bpf-next it works fine:
> >=20
> > $ PKG_CONFIG_PATH=3D/tmp/bpf/lib64/pkgconfig/ ninja -C build-gcc-
> > shared
> > ...
> > Dependency libbpf found: YES 0.0.2
> > ...
> > $ lddtree build-gcc-shared/drivers/librte_pmd_af_xdp.so.1.1=20
> > librte_pmd_af_xdp.so.1.1 =3D> build-gcc-
> > shared/drivers/librte_pmd_af_xdp.so.1.1 (interpreter =3D> none)
> > libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6
> > libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2
> > libnuma.so.1 =3D> /lib/x86_64-linux-gnu/libnuma.so.1
> > librte_ethdev.so.12 =3D> build-gcc-
> > shared/drivers/../lib/librte_ethdev.so.12
> > librte_eal.so.10 =3D> build-gcc-
> > shared/drivers/../lib/librte_eal.so.10
> > librte_kvargs.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_kvargs.so.1
> > librte_net.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_net.so.1
> > librte_mbuf.so.5 =3D> build-gcc-
> > shared/drivers/../lib/librte_mbuf.so.5
> > librte_mempool.so.5 =3D> build-gcc-
> > shared/drivers/../lib/librte_mempool.so.5
> > librte_ring.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_ring.so.2
> > librte_cmdline.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_cmdline.so.2
> > librte_meter.so.2 =3D> build-gcc-
> > shared/drivers/../lib/librte_meter.so.2
> > librte_bus_pci.so.2 =3D> not found
> > librte_pci.so.1 =3D> build-gcc-
> > shared/drivers/../lib/librte_pci.so.1
> > librte_bus_vdev.so.2 =3D> not found
> > libbsd.so.0 =3D> /lib/x86_64-linux-gnu/libbsd.so.0
> > librt.so.1 =3D> /lib/x86_64-linux-gnu/librt.so.1
> > libbpf.so.0 =3D> /tmp/bpf/lib64/libbpf.so.0
> > libelf.so.1 =3D> /lib/x86_64-linux-gnu/libelf.so.1
> > libz.so.1 =3D> /lib/x86_64-linux-gnu/libz.so.1
> > libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0
> > libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6
> > ld-linux-x86-64.so.2 =3D> /lib/x86_64-linux-gnu/ld-linux-x86-
> > 64.so.2
> >=20
> > > > +if bpf_dep.found()
> > > > + build =3D true
> > > > +else
> > > > + bpf_dep =3D cc.find_library('libbpf', required: false)
> > >=20
> > > Also this line can't find it, in log it says "(tried pkgconfig
> > > and
> > > cmake)" and
> > > yes there is no pkgconfig for it, any idea how 'cmake' used?
> >=20
> > The issue here is that it should be cc.find_library('bpf' - not
> > 'libbpf'. I missed this when reviewing, good catch.
> >=20
> > That's because find_library just does a compilation test passing
> > the
> > value to the compiler as a linker flag - so right now it's passing
> > -llibbpf. Fixing this line and the header line below makes it work
> > without pkg-config:
> >=20
> > $ CPPFLAGS=3D-I/tmp/bpf/include LDFLAGS=3D-L/tmp/bpf/lib64 meson testt
> > ...
> > Dependency libbpf found: NO (tried pkgconfig and cmake)
> > Library bpf found: YES
>=20
> After apply the fix in af_xdp pmd's meson.build, now I was able to
> build
> library for af_xdp pmd.
>=20
> $ ls drivers/ |grep xdp
> a715181@@rte_pmd_af_xdp@sha
> a715181@@rte_pmd_af_xdp@sta
> a715181@@tmp_rte_pmd_af_xdp@sta
> librte_pmd_af_xdp.a
> librte_pmd_af_xdp.so
> librte_pmd_af_xdp.so.1
> librte_pmd_af_xdp.so.1.1
> libtmp_rte_pmd_af_xdp.a
> rte_pmd_af_xdp.pmd.c
>=20
> But I found that if I install libbpf to /usr/local/lib64 by default,
> application
> built by meson build will fail to run:
>=20
> $ ./dpdk-testpmd
> ./dpdk-testpmd: error while loading shared libraries: libbpf.so.0:
> cannot open shared object file: No such file or directory
>=20
> While install libbpf to /usr/lib doesn't have this issue (I was
> testing on ubuntu system).
> Is it a expected behavior? Do we need any fix for it?
Hi,
That is expected and distro specific: if your distro doesn't add
/usr/local/lib* to the compiler path, it also won't be in the
LD_LIBRARY_PATH.
So if you do:
LD_LIBRARY_PATH=3D/usr/local/lib64 ./dpdk-testpmd
It should then work. It's not related to the build system, but just to
what the default paths are in the distro.
--=20
Kind regards,
Luca Boccassi