[PATCH] build: fix libpcap detection with unusable header

[Stephen Hemminger]

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> 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>
> > Sent: Tuesday, 7 July 2026 17:16
> > To: Maayan Kashani <mkashani at nvidia.com>
> > Cc: dev at dpdk.org; Raslan Darawsheh <rasland at nvidia.com>;
> > stable at dpdk.org; David Marchand <david.marchand at redhat.com>; Stephen
> > Hemminger <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
> > >
> > > Signed-off-by: Maayan Kashani <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/acb7e96c/attachment.htm>