ebpf-code-legacy packages fetch the kernel-collector flavor selected by an inverted condition
The problem
packaging/cmake/Modules/NetdataEBPFLegacy.cmake decides which kernel-collector tarball flavor (glibc/musl/static) to fetch by testing BUILD_SHARED_LIBS:
if(DEFINED BUILD_SHARED_LIBS)
if(NOT BUILD_SHARED_LIBS)
set(need_static TRUE)
endif()
endif()
(NetdataEBPFLegacy.cmake:14-18)
But CMakeLists.txt:26 sets that variable as a mirror of STATIC_BUILD:
set(BUILD_SHARED_LIBS "${STATIC_BUILD}")
So the selection is inverted relative to its apparent intent:
- a normal build (
STATIC_BUILD=Off, i.e. every DEB and RPM) getsBUILD_SHARED_LIBS=OFF→need_static=TRUE→ fetchesnetdata-kernel-collector-static-*.tar.xz; - a static build (
STATIC_BUILD=On) getsBUILD_SHARED_LIBS=ON→ falls through to the libc detection → fetches theglibc/muslflavor.
The sibling module gets it right by testing the intent directly (NetdataLibBPF.cmake:35-37):
if(STATIC_BUILD)
set(need_static TRUE)
endif()
Why this is a question and not just a fix
The DEB/RPM netdata-ebpf-code-legacy packages have shipped the static tarball's .o files for years, apparently without complaints — which suggests either flavor works at runtime, or that nobody exercising legacy eBPF hit a case where the flavor matters. Aligning the module with NetdataLibBPF.cmake changes the contents of shipped packages (DEB/RPM would start carrying the glibc flavor), so the intended flavor per artifact should be decided by the eBPF/packaging owners before any change:
- Which flavor should DEB/RPM carry —
glibc/muslper the build host, orstatic? - Which flavor should the static installer carry?
- If the current shipped contents are actually correct, the fix is instead to make the condition say what it means (
if(STATIC_BUILD)inverted, or an explicit flavor choice), so the next reader does not have to rediscover this.
Where
packaging/cmake/Modules/NetdataEBPFLegacy.cmake:14-22CMakeLists.txt:26packaging/cmake/Modules/NetdataLibBPF.cmake:35-37(the pattern to align with, whichever direction is chosen)
Source: netdata/netdata