Disable SPDK testing again?

Morten Brørup mb at smartsharesystems.com
Fri Oct 31 10:11:18 CET 2025


> From: David Marchand [mailto:david.marchand at redhat.com]
> Sent: Friday, 31 October 2025 09.39
> 
> Hello,
> 
> The SPDK target in UNH lab has been spewing warnings as SPDK build
> itself compiles and links against a list of libraries and drivers,
> regardless of the upstream dependencies.
> https://github.com/spdk/dpdk/commit/74b1a804eda2ed99d1ecaae5b79de7df6d7
> 4e8ff and
> https://github.com/spdk/spdk/blob/master/dpdkbuild/Makefile#L66
> 
> 
> Until SPDK fixes this on their side (either adding argparse in their
> static list, or using pkg-config for example and stopping patching
> DPDK), linking SPDK binaries fails as the argparse lib now necessary
> to EAL is not pulled:
> 
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_usage':
> eal_common_options.c:(.text+0x16): undefined reference to
> `rte_argparse_print_help'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_collate_args':
> eal_common_options.c:(.text+0x953): undefined reference to
> `rte_argparse_parse'
> /usr/bin/ld.bfd:
> /usr/local/lib/x86_64-linux-
> gnu/librte_eal.a(eal_common_eal_common_options.c.o):
> in function `eal_parse_args':
> eal_common_options.c:(.text+0x343b): undefined reference to
> `rte_argparse_parse_type'
> collect2: error: ld returned 1 exit status
> make[3]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.app.mk:39:
> spdk_lock] Error 1
> make[2]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> lock] Error 2
> make[1]: *** [/root/workspace/Generic-DPDK-Compile-
> Meson/spdk/mk/spdk.subdirs.mk:16:
> thread] Error 2
> 
> 
> While it is just a warning in the CI dashboard, I don't think we
> should waste resources on this testing.
> Opinions?

We should ask ourselves why they are doing that.
Is something wrong (or incomplete) with our handling of -Denable_libs?
Are we including unnecessary optional libs?

It seems like they are using -Ddisable_libs, not -Denable_libs. Don't they know about -Denable_libs?



More information about the ci mailing list