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 6340DA0679
	for <public@inbox.dpdk.org>; Wed,  3 Apr 2019 17:23:20 +0200 (CEST)
Received: from [92.243.14.124] (localhost [127.0.0.1])
	by dpdk.org (Postfix) with ESMTP id AB0B81B49C;
	Wed,  3 Apr 2019 17:23:19 +0200 (CEST)
Received: from mga03.intel.com (mga03.intel.com [134.134.136.65])
 by dpdk.org (Postfix) with ESMTP id E53921B49B
 for <dev@dpdk.org>; Wed,  3 Apr 2019 17:23:17 +0200 (CEST)
X-Amp-Result: UNSCANNABLE
X-Amp-File-Uploaded: False
Received: from orsmga007.jf.intel.com ([10.7.209.58])
 by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384;
 03 Apr 2019 08:23:16 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.60,304,1549958400"; d="scan'208";a="128333634"
Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.35])
 by orsmga007.jf.intel.com with SMTP; 03 Apr 2019 08:23:14 -0700
Received: by  (sSMTP sendmail emulation); Wed, 03 Apr 2019 16:23:13 +0100
Date: Wed, 3 Apr 2019 16:23:13 +0100
From: Bruce Richardson <bruce.richardson@intel.com>
To: Ye Xiaolong <xiaolong.ye@intel.com>
Cc: Luca Boccassi <bluca@debian.org>, Ferruh Yigit <ferruh.yigit@intel.com>,
 dev@dpdk.org
Message-ID: <20190403152313.GB1325@bricha3-MOBL.ger.corp.intel.com>
References: <20190403095939.GA32340@intel.com>
 <56ce5855b02d47a085a8d36451561c400f0b039c.camel@debian.org>
 <0dde8c20e9992047f29d39ad45dcf511244a5297.camel@debian.org>
 <80c81c0c-cf64-59f8-a592-26cd865fbd89@intel.com>
 <37073834d0b9a9f5a6e9f39bac3adc5eb29779ab.camel@debian.org>
 <5bc49c51-04f4-6f73-889d-d3c0ff749784@intel.com>
 <46d92b70a40581462f5ee3ba301c793c4cf0c2df.camel@debian.org>
 <20190403144327.GB36385@intel.com>
 <8f1ac08396f0deaca458201370c08b1334ee6b84.camel@debian.org>
 <20190403151458.GC36385@intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Disposition: inline
In-Reply-To: <20190403151458.GC36385@intel.com>
User-Agent: Mutt/1.11.4 (2019-03-13)
Subject: Re: [dpdk-dev] [PATCH v9 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: <20190403152313.pu3zE7U2GZ6w6IxTPTmrteU6aIe9UN2MTaWvd9SYJto@z>

On Wed, Apr 03, 2019 at 11:14:58PM +0800, Ye Xiaolong wrote:
> On 04/03, Luca Boccassi wrote:
> >On Wed, 2019-04-03 at 22:43 +0800, Ye Xiaolong wrote:
> >> On 04/03, Luca Boccassi wrote:
> >> [snip]
> >> > > Got it.
> >> > > 
> >> > > In above steps, 'libbpf' also build from kernel source tree, will
> >> > > it
> >> > > be problem
> >> > > in you builds to not have it build from source?
> >> > > 
> >> > > If not, taking into account that xsk.h also will be fixed, only
> >> > > 'tools/include/asm/barrier.h' remains the problem, and it looks
> >> > > like
> >> > > it can be
> >> > > solved, please check above.
> >> > 
> >> > libbpf is already packaged separately in Debian and I think other
> >> > distros will follow soon, so it's all good for me once the barrier
> >> > issue is solved.
> >> > 
> >> > https://packages.debian.org/buster/libbpf-dev
> >> > 
> >> > 
> >> > From the makefile's perspective it should not matter where it comes
> >> > from - the headers should be expected to be in /usr/include and the
> >> > library in /usr/lib* - and pkg-config can help with that if
> >> > available.
> >> > And if a user wants to use a custom path, then it's no different
> >> > than
> >> > any of the other dependencies on other external libraries
> >> 
> >> From tools/lib/bpf/Makefile, after make install_lib and make
> >> install_headers,
> >> the headers and library would be put in /usr/local/include/bpf and
> >> /usr/local/lib*,
> >> Is it ok?
> >
> >Yes certainly that's fine, that's expected for local installations, and
> >users can specify a prefix with the upstream's makefile if they want to
> >install somewhere else.
> 
> In my local test, if I run `make install_lib` to install the libbpf.so to 
> /usr/local/lib64, `-lbpf` specified in af_xdp pmd still fails to find the library,
> the build would end up with a lot of undefined references which are defined in libbpf.
> It means during dpdk compilation, it won't search libraries in /usr/local/lib*, right?
> 
> Install the libbpf to /usr/lib64 via `make install_lib prefix=/usr` doesn't have 
> this issue, so shall I just document it in af_xdp.rst or there is other proper
> way to do it?
> 
At a guess I'd say you are using Fedora Linux, right? Fedora is unusual in
that it doesn't by default add /usr/local to the library and header search
paths so you need to explicitly add them to your environment. Other distros
should work fine for this.

/Bruce