* [PATCH] build: fix libpcap detection with unusable header
@ 2026-07-07 13:30 Maayan Kashani
2026-07-07 14:16 ` Bruce Richardson
0 siblings, 1 reply; 6+ messages in thread
From: Maayan Kashani @ 2026-07-07 13:30 UTC (permalink / raw)
To: dev
Cc: mkashani, rasland, stable, Bruce Richardson, David Marchand,
Stephen Hemminger
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
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] build: fix libpcap detection with unusable header
2026-07-07 13:30 [PATCH] build: fix libpcap detection with unusable header Maayan Kashani
@ 2026-07-07 14:16 ` Bruce Richardson
2026-07-08 6:37 ` Maayan Kashani
0 siblings, 1 reply; 6+ messages in thread
From: Bruce Richardson @ 2026-07-07 14:16 UTC (permalink / raw)
To: Maayan Kashani; +Cc: dev, rasland, stable, David Marchand, Stephen Hemminger
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] build: fix libpcap detection with unusable header
2026-07-07 14:16 ` Bruce Richardson
@ 2026-07-08 6:37 ` Maayan Kashani
2026-07-08 7:11 ` Stephen Hemminger
2026-07-08 7:54 ` Bruce Richardson
0 siblings, 2 replies; 6+ messages in thread
From: Maayan Kashani @ 2026-07-08 6:37 UTC (permalink / raw)
To: Bruce Richardson
Cc: dev@dpdk.org, Raslan Darawsheh, stable@dpdk.org, David Marchand,
Stephen Hemminger
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
> >
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] build: fix libpcap detection with unusable header
2026-07-08 6:37 ` Maayan Kashani
@ 2026-07-08 7:11 ` Stephen Hemminger
2026-07-08 8:09 ` Maayan Kashani
2026-07-08 7:54 ` Bruce Richardson
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Hemminger @ 2026-07-08 7:11 UTC (permalink / raw)
To: Maayan Kashani
Cc: Bruce Richardson, dev, Raslan Darawsheh, stable, David Marchand
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] build: fix libpcap detection with unusable header
2026-07-08 6:37 ` Maayan Kashani
2026-07-08 7:11 ` Stephen Hemminger
@ 2026-07-08 7:54 ` Bruce Richardson
1 sibling, 0 replies; 6+ messages in thread
From: Bruce Richardson @ 2026-07-08 7:54 UTC (permalink / raw)
To: Maayan Kashani
Cc: dev@dpdk.org, Raslan Darawsheh, stable@dpdk.org, David Marchand,
Stephen Hemminger
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: [PATCH] build: fix libpcap detection with unusable header
2026-07-08 7:11 ` Stephen Hemminger
@ 2026-07-08 8:09 ` Maayan Kashani
0 siblings, 0 replies; 6+ messages in thread
From: Maayan Kashani @ 2026-07-08 8:09 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Bruce Richardson, dev, Raslan Darawsheh, stable, David Marchand
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2026-07-08 8:09 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-07-07 13:30 [PATCH] build: fix libpcap detection with unusable header Maayan Kashani
2026-07-07 14:16 ` Bruce Richardson
2026-07-08 6:37 ` Maayan Kashani
2026-07-08 7:11 ` Stephen Hemminger
2026-07-08 8:09 ` Maayan Kashani
2026-07-08 7:54 ` Bruce Richardson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox