[PATCH] build: fix libpcap detection with unusable header

[PATCH] build: fix libpcap detection with unusable header

[Maayan Kashani]

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:

  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@dpdk.org

Signed-off-by: Maayan Kashani <mkashani@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@0@'.format(pcap_lib)
-- 
2.21.0

Re: [PATCH] build: fix libpcap detection with unusable header

[Bruce Richardson]

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@dpdk.org
> 
> Signed-off-by: Maayan Kashani <mkashani@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@0@'.format(pcap_lib)
> -- 
> 2.21.0
> 

RE: [PATCH] build: fix libpcap detection with unusable header

[Maayan Kashani]

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@intel.com>
> Sent: Tuesday, 7 July 2026 17:16
> To: Maayan Kashani <mkashani@nvidia.com>
> Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>;
> stable@dpdk.org; David Marchand <david.marchand@redhat.com>; Stephen
> Hemminger <stephen@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@dpdk.org
> >
> > Signed-off-by: Maayan Kashani <mkashani@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@0@'.format(pcap_lib)
> > --
> > 2.21.0
> >

Re: [PATCH] build: fix libpcap detection with unusable header

[Stephen Hemminger]

[-- Attachment #1: Type: text/plain, Size: 3453 bytes --]

Not sure. Working around busted packages in DPDK is a bad idea.

On Wed, Jul 8, 2026, 08:38 Maayan Kashani <mkashani@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@intel.com>
> > Sent: Tuesday, 7 July 2026 17:16
> > To: Maayan Kashani <mkashani@nvidia.com>
> > Cc: dev@dpdk.org; Raslan Darawsheh <rasland@nvidia.com>;
> > stable@dpdk.org; David Marchand <david.marchand@redhat.com>; Stephen
> > Hemminger <stephen@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@dpdk.org
> > >
> > > Signed-off-by: Maayan Kashani <mkashani@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@0@'.format(pcap_lib)
> > > --
> > > 2.21.0
> > >
>

[-- Attachment #2: Type: text/html, Size: 5045 bytes --]

RE: [PATCH] build: fix libpcap detection with unusable header

[Maayan Kashani]

[-- Attachment #1: Type: text/plain, Size: 4071 bytes --]

Understood. Thanks.

Regards,
Maayan Kashani

From: Stephen Hemminger <stephen@networkplumber.org>
Sent: Wednesday, 8 July 2026 10:11
To: Maayan Kashani <mkashani@nvidia.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>; dev <dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com>; stable <stable@dpdk.org>; David Marchand <david.marchand@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@nvidia.com<mailto:mkashani@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@intel.com<mailto:bruce.richardson@intel.com>>
> Sent: Tuesday, 7 July 2026 17:16
> To: Maayan Kashani <mkashani@nvidia.com<mailto:mkashani@nvidia.com>>
> Cc: dev@dpdk.org<mailto:dev@dpdk.org>; Raslan Darawsheh <rasland@nvidia.com<mailto:rasland@nvidia.com>>;
> stable@dpdk.org<mailto:stable@dpdk.org>; David Marchand <david.marchand@redhat.com<mailto:david.marchand@redhat.com>>; Stephen
> Hemminger <stephen@networkplumber.org<mailto:stephen@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@dpdk.org<mailto:stable@dpdk.org>
> >
> > Signed-off-by: Maayan Kashani <mkashani@nvidia.com<mailto:mkashani@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@0@'.format(pcap_lib)
> > --
> > 2.21.0
> >

[-- Attachment #2: Type: text/html, Size: 8741 bytes --]

Re: [PATCH] build: fix libpcap detection with unusable header

[Bruce Richardson]

On Wed, Jul 08, 2026 at 06:37:59AM +0000, Maayan Kashani 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.”
> 
I would disagree. Following that logic of checking for broken packages,
you're only handling a very small subset of that. If we start checking
this, we really should check for each and every definition in the file that
we need - otherwise we can still have issues with a broken package, for
example, it's broken in missing one definition that we need.

IMHO, in all these cases its better to let things fail, rather than working
around them, in order to prompt correction of the broken package.

/Bruce