From mboxrd@z Thu Jan 1 00:00:00 1970 From: Luca Boccassi Subject: Re: [PATCH v1 1/6] net/af_xdp: introduce AF_XDP PMD driver Date: Mon, 25 Mar 2019 10:42:26 +0000 Message-ID: References: <20190301080947.91086-1-xiaolong.ye@intel.com> <20190301080947.91086-2-xiaolong.ye@intel.com> <20190302081407.GD100586@intel.com> <20190317033425.GA103486@intel.com> <1553429237.20876.3.camel@debian.org> <20190325024559.GB35864@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Cc: dev@dpdk.org, Qi Zhang , "Karlsson, Magnus" To: Ye Xiaolong Return-path: Received: from mail-wm1-f65.google.com (mail-wm1-f65.google.com [209.85.128.65]) by dpdk.org (Postfix) with ESMTP id 5FD8A2BF4 for ; Mon, 25 Mar 2019 11:42:29 +0100 (CET) Received: by mail-wm1-f65.google.com with SMTP id o10so1207166wmc.1 for ; Mon, 25 Mar 2019 03:42:29 -0700 (PDT) In-Reply-To: <20190325024559.GB35864@intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Mon, 2019-03-25 at 10:45 +0800, Ye Xiaolong wrote: > On 03/24, Luca Boccassi wrote: > > On Sun, 2019-03-17 at 11:34 +0800, Ye Xiaolong wrote: > > > On 03/02, Ye Xiaolong wrote: > > > > > > _LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_PACKET) +=3D > > > > > > -lrte_pmd_af_packet > > > > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_XDP) +=3D > > > > > > -lrte_pmd_af_xdp > > > > > > -lelf -lbpf > > > > >=20 > > > > > Are symbols from libelf being used by the PMD? > > > >=20 > > > > Hmm, it is a leftover of RFC, libelf is no longer needed in > > > > this > > > > version, will > > > > remove it in next version. > > > >=20 > > >=20 > > > Correction, libelf is needed for libbpf, so we still need to keep > > > it.=20 > >=20 > > If libbpf needs libelf for its internal usage, it should be linked > > against it itself. Unless symbols from libelf are used in static > > functions defined in libbpf's public headers. Is this the case? > >=20 >=20 > Yes, that's the case. without the libelf, it would have build error > as below, > and these symbols are used in static functions of libbpf. >=20 > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_nextscn' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_rawdata' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_memory' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `gelf_getrel' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_strptr' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_end' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_getscn' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_begin' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `gelf_getsym' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_version' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `gelf_getehdr' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `elf_getdata' > /usr/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/libbpf.so: > undefined reference to `gelf_getshdr' >=20 > Thanks, > Xiaolong Looking at that list, at least the very first symbol is not used by a public header, but internally in libbpf: $ grep -r elf_nextscn libbpf.c: while ((scn =3D elf_nextscn(elf, scn)) !=3D NULL) { https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/tools= /lib/bpf/libbpf.c#n793 None of those symbols are used from the public headers: $ grep elf_ bpf.h libbpf.h btf.h $ Therefore, this is an omission in libbpf's Makefile, as it must link against libelf. Please raise a ticket or send a patch upstream, and remove the -lelf from DPDK's makefiles. --=20 Kind regards, Luca Boccassi