[PATCH] build: fix libpcap detection with unusable header
Maayan Kashani
mkashani at nvidia.com
Wed Jul 8 10:09:19 CEST 2026
Understood. Thanks.
Regards,
Maayan Kashani
From: Stephen Hemminger <stephen at networkplumber.org>
Sent: Wednesday, 8 July 2026 10:11
To: Maayan Kashani <mkashani at nvidia.com>
Cc: Bruce Richardson <bruce.richardson at intel.com>; dev <dev at dpdk.org>; Raslan Darawsheh <rasland at nvidia.com>; stable <stable at dpdk.org>; David Marchand <david.marchand at redhat.com>
Subject: Re: [PATCH] build: fix libpcap detection with unusable header
External email: Use caution opening links or attachments
Not sure. Working around busted packages in DPDK is a bad idea.
On Wed, Jul 8, 2026, 08:38 Maayan Kashani <mkashani at nvidia.com<mailto:mkashani at nvidia.com>> wrote:
Hi, Bruce,
we encountered DPDK build issue on Tencent 4.6.
It is not expected; the package/image appears corrupted.
RPM verification confirms the headers differ from the packaged contents.
The DPDK change is still valid because optional dependency detection should
test for usable declarations, not just file existence and library presence.”
Regards,
Maayan Kashani
> -----Original Message-----
> From: Bruce Richardson <bruce.richardson at intel.com<mailto:bruce.richardson at intel.com>>
> Sent: Tuesday, 7 July 2026 17:16
> To: Maayan Kashani <mkashani at nvidia.com<mailto:mkashani at nvidia.com>>
> Cc: dev at dpdk.org<mailto:dev at dpdk.org>; Raslan Darawsheh <rasland at nvidia.com<mailto:rasland at nvidia.com>>;
> stable at dpdk.org<mailto:stable at dpdk.org>; David Marchand <david.marchand at redhat.com<mailto:david.marchand at redhat.com>>; Stephen
> Hemminger <stephen at networkplumber.org<mailto:stephen at networkplumber.org>>
> Subject: Re: [PATCH] build: fix libpcap detection with unusable header
>
> External email: Use caution opening links or attachments
>
>
> On Tue, Jul 07, 2026 at 04:30:28PM +0300, Maayan Kashani wrote:
> > The libpcap detection only checked that the library was present, that
> > <pcap.h> could be included, and that a trivial program links. None of
> > these fail when a distribution ships a libpcap-devel package whose
> > <pcap.h> is empty (present but declaring nothing) while libpcap.so is
> > installed: has_header() passes on an empty file and the link test does
> > not reference any pcap symbol. RTE_HAS_LIBPCAP was then set and the
> > pcap-dependent code (bpf_convert.c, port source/sink, dumpcap) failed
> > to build with errors such as:
> >
>
> Why would a distribution ship a devel package with an empty header file for
> pcap.h? Is that expected behaviour in some scenario that I'm unaware of,
> because it seems strange to me?
>
> /Bruce
>
> > bpf_convert.c: error: invalid use of undefined type
> > 'const struct bpf_insn'
> >
> > Require an actual pcap declaration (pcap_create) to be visible in the
> > header before enabling libpcap support, so a broken or empty header
> > disables the optional pcap features instead of breaking the build.
> >
> > Fixes: d6024c0a6757 ("build: cleanup libpcap dependent components")
> > Cc: stable at dpdk.org<mailto:stable at dpdk.org>
> >
> > Signed-off-by: Maayan Kashani <mkashani at nvidia.com<mailto:mkashani at nvidia.com>>
> > ---
> > config/meson.build | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/config/meson.build b/config/meson.build index
> > d7f5e55c18f..4bfb8535781 100644
> > --- a/config/meson.build
> > +++ b/config/meson.build
> > @@ -290,7 +290,10 @@ if not pcap_dep.found()
> > # pcap got a pkg-config file only in 1.9.0
> > pcap_dep = cc.find_library(pcap_lib, required: false) endif -if
> > (pcap_dep.found() and cc.has_header('pcap.h', dependencies: pcap_dep)
> > +# has_header() passes even when pcap.h is empty; require a real
> declaration.
> > +if (pcap_dep.found()
> > + and cc.has_header_symbol('pcap.h', 'pcap_create', dependencies:
> pcap_dep,
> > + args: '-D_GNU_SOURCE')
> > and cc.links(min_c_code, dependencies: pcap_dep))
> > dpdk_conf.set('RTE_HAS_LIBPCAP', 1)
> > dpdk_extra_ldflags += '-l at 0@'.format(pcap_lib)
> > --
> > 2.21.0
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/stable/attachments/20260708/8891aef7/attachment.htm>
More information about the stable
mailing list