On 03/26, Luca Boccassi wrote:
>On Tue, 2019-03-26 at 10:18 +0800, Ye Xiaolong wrote:
>> On 03/25, Luca Boccassi wrote:
>> > 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) +=
>> > > > > > > > -lrte_pmd_af_packet
>> > > > > > > > +_LDLIBS-$(CONFIG_RTE_LIBRTE_PMD_AF_XDP) +=
>> > > > > > > > -lrte_pmd_af_xdp
>> > > > > > > > -lelf -lbpf
>> > > > > > >
>> > > > > > > Are symbols from libelf being used by the PMD?
>> > > > > >
>> > > > > > Hmm, it is a leftover of RFC, libelf is no longer needed in
>> > > > > > this
>> > > > > > version, will
>> > > > > > remove it in next version.
>> > > > > >
>> > > > >
>> > > > > Correction, libelf is needed for libbpf, so we still need to
>> > > > > keep
>> > > > > it.
>> > > >
>> > > > 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?
>> > > >
>> > >
>> > > 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.
>> > >
>> > > /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'
>> > >
>> > > 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 = elf_nextscn(elf, scn)) != 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.
>>
>> As it may need sometime for kernel community to handle the libbpf's
>> Makefile,
>> We may still need the -lelf for af_xdp pmd currently, I'll remove it
>> later after
>> libbpf correct to link against libelf. Is it acceptable?
>>
>> Thanks,
>> Xiaolong
>
>Isn't the final version not out yet anyway till May? Can the fix be
>included before the release?
I think so.
Thanks,
Xiaolong
>
>--
>Kind regards,
>Luca Boccassi
