Not sure. Working around busted packages in DPDK is a bad idea. On Wed, Jul 8, 2026, 08:38 Maayan Kashani <[email protected]> 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 <[email protected]> > > Sent: Tuesday, 7 July 2026 17:16 > > To: Maayan Kashani <[email protected]> > > Cc: [email protected]; Raslan Darawsheh <[email protected]>; > > [email protected]; David Marchand <[email protected]>; Stephen > > Hemminger <[email protected]> > > 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: [email protected] > > > > > > Signed-off-by: Maayan Kashani <[email protected]> > > > --- > > > 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 > > > >
