[Buildroot] [PATCH 0/5] package/kmod version 34 and Meson build

[Buildroot] [PATCH 0/5] package/kmod version 34 and Meson build

[Fiona Klute via buildroot]

Hi everyone,

this series updates package/kmod to 34.2, and switches it to the new
Meson build. The upstream changelog for 34 states the old Autotools
build will be removed with the next major version. I've structured the
series to switch step by step:

1: bump the version (should be backportable, if stable maintainers see
   the need)
2 & 3: tidy up to prepare for build system switch
4: do the build system switch
5: enable the new dlopen feature for compression libraries (if any)

Best regards,
Fiona


Fiona Klute (5):
  package/kmod: bump to 34.2
  support/testing/tests/package/test_kmod.py: use current 6.6.x kernel
  Revert "kmod: workaround for microblaze ld bug"
  package/kmod: switch to Meson build
  package/kmod: enable dlopen() for compression libraries (if any)

 .checkpackageignore                        |  1 -
 package/kmod/0001-fix-O_CLOEXEC.patch      | 48 ------------
 package/kmod/kmod.hash                     |  2 +-
 package/kmod/kmod.mk                       | 87 ++++++++--------------
 support/testing/tests/package/test_kmod.py |  2 +-
 5 files changed, 35 insertions(+), 105 deletions(-)
 delete mode 100644 package/kmod/0001-fix-O_CLOEXEC.patch

-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 1/5] package/kmod: bump to 34.2

[Fiona Klute via buildroot]

Upstream changelog for 34:
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/tree/NEWS?h=v34.2

34.2 contains a few bugfixes on top, see the Git log:
https://git.kernel.org/pub/scm/utils/kernel/kmod/kmod.git/log/?h=v34.2

Remove 0001-fix-O_CLOEXEC.patch. This patch does not apply cleanly
with 34, and while it could be updated easily it is needed only for
kernel versions before 2.6.23, which was released in 2007. Older
versions should not be relevant anymore.

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 .checkpackageignore                   |  1 -
 package/kmod/0001-fix-O_CLOEXEC.patch | 48 ---------------------------
 package/kmod/kmod.hash                |  2 +-
 package/kmod/kmod.mk                  |  2 +-
 4 files changed, 2 insertions(+), 51 deletions(-)
 delete mode 100644 package/kmod/0001-fix-O_CLOEXEC.patch

diff --git a/.checkpackageignore b/.checkpackageignore
index f4a428d4cf..f24cc77e3e 100644
--- a/.checkpackageignore
+++ b/.checkpackageignore
@@ -466,7 +466,6 @@ package/janus-gateway/0001-disable-ssp.patch lib_patch.Upstream
 package/kexec-lite/0001-clean-restart.patch lib_patch.Upstream
 package/keyutils/0001-fix-install-rule.patch lib_patch.Upstream
 package/keyutils/0002-cifs.patch lib_patch.Sob lib_patch.Upstream
-package/kmod/0001-fix-O_CLOEXEC.patch lib_patch.Upstream
 package/kodi/S50kodi Shellcheck lib_sysv.Variables
 package/lbase64/0001-retro-compatible-with-Lua-5.1.patch lib_patch.Upstream
 package/lcdproc/0001-LCDd.conf.patch lib_patch.Upstream
diff --git a/package/kmod/0001-fix-O_CLOEXEC.patch b/package/kmod/0001-fix-O_CLOEXEC.patch
deleted file mode 100644
index 145ac34207..0000000000
--- a/package/kmod/0001-fix-O_CLOEXEC.patch
+++ /dev/null
@@ -1,48 +0,0 @@
-From b39a62f6682463bcd47480348fac3dcd209a19a5 Mon Sep 17 00:00:00 2001
-From: Robert Yang <liezhi.yang@windriver.com>
-Date: Wed, 22 Jan 2014 01:06:40 -0500
-Subject: [PATCH] Add dummy definition of O_CLOEXEC
-
-O_CLOEXEC is introduced from Linux 2.6.23, so old kernel doesn't have
-it, we need check before use.
-
-This patch is much more like a workaround, since it may need fcntl() use
-FD_CLOEXEC to replace.
-
-This problem was reported by "Ting Liu <b28495@freescale.com>"
-
-[Thomas De Schampheleire <thomas.de.schampheleire@gmail.com:
- - move dummy definition from libkmod-internal.h to missing.h
- - update commit title]
-
-[Vicente: Adapt this patch to version 19.]
-
-Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
-Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
-
-Upstream-status: rejected, suggests to add in buildroot instead [1]
-
-[1] http://news.gmane.org/find-root.php?message_id=1412062906%2d27378%2d1%2dgit%2dsend%2demail%2dpatrickdepinguin%40gmail.com
-
----
- shared/missing.h |    4 ++++
- 1 files changed, 4 insertions(+), 0 deletions(-)
-
-diff --git a/shared/missing.h b/shared/missing.h
-index 4c0d136..e123e98 100644
---- a/shared/missing.h
-+++ b/shared/missing.h
-@@ -19,6 +19,10 @@
- # define __NR_finit_module -1
- #endif
- 
-+#ifndef O_CLOEXEC
-+#define O_CLOEXEC 0
-+#endif
-+
- #ifndef HAVE_FINIT_MODULE
- #include <errno.h>
- 
--- 
-1.7.1
-
diff --git a/package/kmod/kmod.hash b/package/kmod/kmod.hash
index 46a2d538ad..032f96adfe 100644
--- a/package/kmod/kmod.hash
+++ b/package/kmod/kmod.hash
@@ -1,5 +1,5 @@
 # From https://www.kernel.org/pub/linux/utils/kernel/kmod/sha256sums.asc
-sha256  dc768b3155172091f56dc69430b5481f2d76ecd9ccb54ead8c2540dbcf5ea9bc  kmod-33.tar.xz
+sha256  5a5d5073070cc7e0c7a7a3c6ec2a0e1780850c8b47b3e3892226b93ffcb9cb54  kmod-34.2.tar.xz
 
 # Locally calculated
 sha256  6095e9ffa777dd22839f7801aa845b31c9ed07f3d6bf8a26dc5d2dec8ccc0ef3  libkmod/COPYING
diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index cbf89bca9d..db9b3cdf21 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -4,7 +4,7 @@
 #
 ################################################################################
 
-KMOD_VERSION = 33
+KMOD_VERSION = 34.2
 KMOD_SOURCE = kmod-$(KMOD_VERSION).tar.xz
 KMOD_SITE = $(BR2_KERNEL_MIRROR)/linux/utils/kernel/kmod
 KMOD_INSTALL_STAGING = YES
-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 2/5] support/testing/tests/package/test_kmod.py: use current 6.6.x kernel

[Fiona Klute via buildroot]

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 support/testing/tests/package/test_kmod.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/support/testing/tests/package/test_kmod.py b/support/testing/tests/package/test_kmod.py
index 1d9ea535fc..e11d3b702c 100644
--- a/support/testing/tests/package/test_kmod.py
+++ b/support/testing/tests/package/test_kmod.py
@@ -15,7 +15,7 @@ class TestKmod(infra.basetest.BRTest):
         BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0"
         BR2_LINUX_KERNEL=y
         BR2_LINUX_KERNEL_CUSTOM_VERSION=y
-        BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6.35"
+        BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="6.6.135"
         BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
         BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/qemu/aarch64-virt/linux.config"
         BR2_LINUX_KERNEL_CONFIG_FRAGMENT_FILES="{kernel_fragment}"
-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 3/5] Revert "kmod: workaround for microblaze ld bug"

[Fiona Klute via buildroot]

This reverts commit 0d81107f021bf2a663f102bace1e3f9590641170. The bug
the workaround is for was fixed in binutils 2.29.51 (first release
listed in bfd/ChangeLog after the fix), which is by now far older than
any version supported by Buildroot.

Compile tested with qemu_microblazeel_mmu_defconfig plus
BR2_PACKAGE_KMOD=y.

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 package/kmod/kmod.mk | 6 ------
 1 file changed, 6 deletions(-)

diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index db9b3cdf21..bcf65fd9be 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -17,12 +17,6 @@ KMOD_LICENSE_FILES = libkmod/COPYING
 
 KMOD_CPE_ID_VENDOR = kernel
 
-# --gc-sections triggers binutils ld segfault
-# https://sourceware.org/bugzilla/show_bug.cgi?id=21180
-ifeq ($(BR2_microblaze),y)
-KMOD_CONF_ENV += cc_cv_LDFLAGS__Wl___gc_sections=false
-endif
-
 # static linking not supported, see
 # https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=b7016153ec8
 KMOD_CONF_OPTS = --disable-static --enable-shared
-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 3/5] Revert "kmod: workaround for microblaze ld bug"

[Thomas Perale via buildroot]

In reply of:
> This reverts commit 0d81107f021bf2a663f102bace1e3f9590641170. The bug
> the workaround is for was fixed in binutils 2.29.51 (first release
> listed in bfd/ChangeLog after the fix), which is by now far older than
> any version supported by Buildroot.
> 
> Compile tested with qemu_microblazeel_mmu_defconfig plus
> BR2_PACKAGE_KMOD=y.
> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>

Applied to 2025.02.x & 2026.02.x. Thanks

> ---
>  package/kmod/kmod.mk | 6 ------
>  1 file changed, 6 deletions(-)
> 
> diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
> index db9b3cdf21..bcf65fd9be 100644
> --- a/package/kmod/kmod.mk
> +++ b/package/kmod/kmod.mk
> @@ -17,12 +17,6 @@ KMOD_LICENSE_FILES = libkmod/COPYING
>  
>  KMOD_CPE_ID_VENDOR = kernel
>  
> -# --gc-sections triggers binutils ld segfault
> -# https://sourceware.org/bugzilla/show_bug.cgi?id=21180
> -ifeq ($(BR2_microblaze),y)
> -KMOD_CONF_ENV += cc_cv_LDFLAGS__Wl___gc_sections=false
> -endif
> -
>  # static linking not supported, see
>  # https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=b7016153ec8
>  KMOD_CONF_OPTS = --disable-static --enable-shared
> -- 
> 2.53.0
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Fiona Klute via buildroot]

The upstream changelog for version 34 states that the next major
version will drop the Autotools build, and the 34 series is meant for
distros to switch.

Notable changes in the Buildroot package:

* The Meson build handles symlink install, so we can drop the post
  install hooks.

* The previous point also means that host-kmod now installs the full
  set of tools.

* Explicitly disable openssl support in host-kmod tools. It is enabled
  by default and the build fails if OpenSSL cannot be found. In the
  autotools build it was not explicitly set.

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 package/kmod/kmod.mk | 75 +++++++++++++++++---------------------------
 1 file changed, 28 insertions(+), 47 deletions(-)

diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index bcf65fd9be..e1f713dc01 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -17,43 +17,43 @@ KMOD_LICENSE_FILES = libkmod/COPYING
 
 KMOD_CPE_ID_VENDOR = kernel
 
-# static linking not supported, see
-# https://git.kernel.org/cgit/utils/kernel/kmod/kmod.git/commit/?id=b7016153ec8
-KMOD_CONF_OPTS = --disable-static --enable-shared
-
-KMOD_CONF_OPTS += --disable-manpages
-HOST_KMOD_CONF_OPTS = --disable-manpages
+KMOD_CONF_OPTS = -Dmanpages=false
+HOST_KMOD_CONF_OPTS = -Dmanpages=false
 
 ifeq ($(BR2_PACKAGE_BASH_COMPLETION),y)
-KMOD_CONF_OPTS += --with-bashcompletiondir=/usr/share/bash-completion/completions
+KMOD_CONF_OPTS += -Dbashcompletiondir=/usr/share/bash-completion/completions
+else
+KMOD_CONF_OPTS += -Dbashcompletiondir=no
 endif
 
+KMOD_CONF_OPTS += -Dfishcompletiondir=no -Dzshcompletiondir=no
+
 ifeq ($(BR2_PACKAGE_ZLIB),y)
 KMOD_DEPENDENCIES += zlib
-KMOD_CONF_OPTS += --with-zlib
+KMOD_CONF_OPTS += -Dzlib=enabled
 else
-KMOD_CONF_OPTS += --without-zlib
+KMOD_CONF_OPTS += -Dzlib=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_ZSTD),y)
 KMOD_DEPENDENCIES += zstd
-KMOD_CONF_OPTS += --with-zstd
+KMOD_CONF_OPTS += -Dzstd=enabled
 else
-KMOD_CONF_OPTS += --without-zstd
+KMOD_CONF_OPTS += -Dzstd=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_XZ),y)
 KMOD_DEPENDENCIES += xz
-KMOD_CONF_OPTS += --with-xz
+KMOD_CONF_OPTS += -Dxz=enabled
 else
-KMOD_CONF_OPTS += --without-xz
+KMOD_CONF_OPTS += -Dxz=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_OPENSSL),y)
 KMOD_DEPENDENCIES += openssl
-KMOD_CONF_OPTS += --with-openssl
+KMOD_CONF_OPTS += -Dopenssl=enabled
 else
-KMOD_CONF_OPTS += --without-openssl
+KMOD_CONF_OPTS += -Dopenssl=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_KMOD_TOOLS),y)
@@ -62,61 +62,42 @@ ifeq ($(BR2_PACKAGE_KMOD_TOOLS),y)
 KMOD_LICENSE += , GPL-2.0+ (tools)
 KMOD_LICENSE_FILES += COPYING
 
-# /sbin is really /usr/sbin with merged /usr, and /usr/sbin is
-# really /usr/bin with merged-bin, so adjust relative symlink
 ifeq ($(BR2_ROOTFS_MERGED_USR),y)
 ifeq ($(BR2_ROOTFS_MERGED_BIN),y)
-KMOD_BIN_PATH = kmod
-KMOD_SBIN_DIR = bin
+KMOD_CONF_OPTS += -Dsbindir=bin
 else
-KMOD_BIN_PATH = ../bin/kmod
-KMOD_SBIN_DIR = sbin
+KMOD_CONF_OPTS += -Dsbindir=sbin
 endif
 else
-KMOD_BIN_PATH = ../usr/bin/kmod
-KMOD_SBIN_DIR = sbin
+KMOD_CONF_OPTS += -Dsbindir=/sbin
 endif
 
-define KMOD_INSTALL_TOOLS
-	for i in depmod insmod lsmod modinfo modprobe rmmod; do \
-		ln -sf $(KMOD_BIN_PATH) $(TARGET_DIR)/$(KMOD_SBIN_DIR)/$$i; \
-	done
-endef
-
-KMOD_POST_INSTALL_TARGET_HOOKS += KMOD_INSTALL_TOOLS
 else
-KMOD_CONF_OPTS += --disable-tools
+KMOD_CONF_OPTS += -Dtools=false
 endif
 
 ifeq ($(BR2_PACKAGE_HOST_KMOD_GZ),y)
 HOST_KMOD_DEPENDENCIES += host-zlib
-HOST_KMOD_CONF_OPTS += --with-zlib
+HOST_KMOD_CONF_OPTS += -Dzlib=enabled
 else
-HOST_KMOD_CONF_OPTS += --without-zlib
+HOST_KMOD_CONF_OPTS += -Dzlib=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_HOST_KMOD_ZSTD),y)
 HOST_KMOD_DEPENDENCIES += host-zstd
-HOST_KMOD_CONF_OPTS += --with-zstd
+HOST_KMOD_CONF_OPTS += -Dzstd=enabled
 else
-HOST_KMOD_CONF_OPTS += --without-zstd
+HOST_KMOD_CONF_OPTS += -Dzstd=disabled
 endif
 
 ifeq ($(BR2_PACKAGE_HOST_KMOD_XZ),y)
 HOST_KMOD_DEPENDENCIES += host-xz
-HOST_KMOD_CONF_OPTS += --with-xz
+HOST_KMOD_CONF_OPTS += -Dxz=enabled
 else
-HOST_KMOD_CONF_OPTS += --without-xz
+HOST_KMOD_CONF_OPTS += -Dxz=disabled
 endif
 
-# We only install depmod, since that's the only tool used for the
-# host.
-define HOST_KMOD_INSTALL_TOOLS
-	mkdir -p $(HOST_DIR)/sbin/
-	ln -sf ../bin/kmod $(HOST_DIR)/sbin/depmod
-endef
-
-HOST_KMOD_POST_INSTALL_HOOKS += HOST_KMOD_INSTALL_TOOLS
+HOST_KMOD_CONF_OPTS += -Dopenssl=disabled
 
-$(eval $(autotools-package))
-$(eval $(host-autotools-package))
+$(eval $(meson-package))
+$(eval $(host-meson-package))
-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Marcus Hoffmann via buildroot]

Hi Fiona,

thanks for this patch, I have one question below, otherwise this looks good.

On 4/25/26 10:56, Fiona Klute via buildroot wrote:
> The upstream changelog for version 34 states that the next major
> version will drop the Autotools build, and the 34 series is meant for
> distros to switch.
> 
> Notable changes in the Buildroot package:
> 
> * The Meson build handles symlink install, so we can drop the post
>    install hooks.
> 
> * The previous point also means that host-kmod now installs the full
>    set of tools.
> 
> * Explicitly disable openssl support in host-kmod tools. It is enabled
>    by default and the build fails if OpenSSL cannot be found. In the
>    autotools build it was not explicitly set.
> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
> ---
> [...]
>   
> -# /sbin is really /usr/sbin with merged /usr, and /usr/sbin is
> -# really /usr/bin with merged-bin, so adjust relative symlink
>   ifeq ($(BR2_ROOTFS_MERGED_USR),y)
>   ifeq ($(BR2_ROOTFS_MERGED_BIN),y)
> -KMOD_BIN_PATH = kmod
> -KMOD_SBIN_DIR = bin
> +KMOD_CONF_OPTS += -Dsbindir=bin
>   else
> -KMOD_BIN_PATH = ../bin/kmod
> -KMOD_SBIN_DIR = sbin
> +KMOD_CONF_OPTS += -Dsbindir=sbin
>   endif
>   else
> -KMOD_BIN_PATH = ../usr/bin/kmod
> -KMOD_SBIN_DIR = sbin
> +KMOD_CONF_OPTS += -Dsbindir=/sbin
>   endif

Is the bindir/sbindir logic still required actually? I'd have hoped that 
meson does this correctly on it's own (afaict these are built-in meson 
flags, that supposedly are also filled in with some sensible default?)

Have you tested removing this altogether?

>   
> -define KMOD_INSTALL_TOOLS
> -	for i in depmod insmod lsmod modinfo modprobe rmmod; do \
> -		ln -sf $(KMOD_BIN_PATH) $(TARGET_DIR)/$(KMOD_SBIN_DIR)/$$i; \
> -	done
> -endef
> -
> -KMOD_POST_INSTALL_TARGET_HOOKS += KMOD_INSTALL_TOOLS
>   else
> -KMOD_CONF_OPTS += --disable-tools
> +KMOD_CONF_OPTS += -Dtools=false> [...]

Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Fiona Klute via buildroot]

Hi Marcus!

Am 30.04.26 um 14:46 schrieb Marcus Hoffmann:
> Hi Fiona,
> 
> thanks for this patch, I have one question below, otherwise this looks 
> good.
> 
> On 4/25/26 10:56, Fiona Klute via buildroot wrote:
>> The upstream changelog for version 34 states that the next major
>> version will drop the Autotools build, and the 34 series is meant for
>> distros to switch.
>>
>> Notable changes in the Buildroot package:
>>
>> * The Meson build handles symlink install, so we can drop the post
>>    install hooks.
>>
>> * The previous point also means that host-kmod now installs the full
>>    set of tools.
>>
>> * Explicitly disable openssl support in host-kmod tools. It is enabled
>>    by default and the build fails if OpenSSL cannot be found. In the
>>    autotools build it was not explicitly set.
>>
>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>> ---
>> [...]
>> -# /sbin is really /usr/sbin with merged /usr, and /usr/sbin is
>> -# really /usr/bin with merged-bin, so adjust relative symlink
>>   ifeq ($(BR2_ROOTFS_MERGED_USR),y)
>>   ifeq ($(BR2_ROOTFS_MERGED_BIN),y)
>> -KMOD_BIN_PATH = kmod
>> -KMOD_SBIN_DIR = bin
>> +KMOD_CONF_OPTS += -Dsbindir=bin
>>   else
>> -KMOD_BIN_PATH = ../bin/kmod
>> -KMOD_SBIN_DIR = sbin
>> +KMOD_CONF_OPTS += -Dsbindir=sbin
>>   endif
>>   else
>> -KMOD_BIN_PATH = ../usr/bin/kmod
>> -KMOD_SBIN_DIR = sbin
>> +KMOD_CONF_OPTS += -Dsbindir=/sbin
>>   endif
> 
> Is the bindir/sbindir logic still required actually? I'd have hoped that 
> meson does this correctly on it's own (afaict these are built-in meson 
> flags, that supposedly are also filled in with some sensible default?)
> 
> Have you tested removing this altogether?

I don't see any merged-usr (or /usr/bin) handling in pkg-meson.mk. Which 
makes sense: Almost all packages should install to /usr even without 
merged-usr, so packages that need to install to /sbin or /bin will need 
to override.

We could probably remove the BR2_ROOTFS_MERGED_BIN=y case (but I haven't 
tested that), because with /usr/sbin as a symlink to /usr/bin the 
difference shouldn't matter. Makes me wonder why it was originally added 
though, because the symlinks haven't changed.

I have tested with and without BR2_ROOTFS_MERGED_USR=y, to get the 
symlinks in /sbin with BR2_ROOTFS_MERGED_USR=n as before we need 
-Dsbindir=/sbin (the Meson default is ${prefix}/sbin).

Whether that makes sense with the kmod binary in /usr/bin is a different 
question: If /usr is on a separate partition (the ancient reason for the 
split), the symlinks will be broken until that is mounted. I simply kept 
the same behavior as before. If placing the symlinks in /usr/sbin in 
builds with BR2_ROOTFS_MERGED_USR=n is fine, we can remove this whole 
mess of conditionals. :-)

Best regards,
Fiona

>> -define KMOD_INSTALL_TOOLS
>> -    for i in depmod insmod lsmod modinfo modprobe rmmod; do \
>> -        ln -sf $(KMOD_BIN_PATH) $(TARGET_DIR)/$(KMOD_SBIN_DIR)/$$i; \
>> -    done
>> -endef
>> -
>> -KMOD_POST_INSTALL_TARGET_HOOKS += KMOD_INSTALL_TOOLS
>>   else
>> -KMOD_CONF_OPTS += --disable-tools
>> +KMOD_CONF_OPTS += -Dtools=false> [...]
> 
> Marcus

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Marcus Hoffmann via buildroot]

+Yann, who added the MERGED_BIN handling in kmod.

On 4/30/26 15:46, Fiona Klute via buildroot wrote:
> Hi Marcus!
> 
> Am 30.04.26 um 14:46 schrieb Marcus Hoffmann:
>> Hi Fiona,
>>
>> thanks for this patch, I have one question below, otherwise this looks 
>> good.
>>
>>> [...]
>>> -# /sbin is really /usr/sbin with merged /usr, and /usr/sbin is
>>> -# really /usr/bin with merged-bin, so adjust relative symlink
>>>   ifeq ($(BR2_ROOTFS_MERGED_USR),y)
>>>   ifeq ($(BR2_ROOTFS_MERGED_BIN),y)
>>> -KMOD_BIN_PATH = kmod
>>> -KMOD_SBIN_DIR = bin
>>> +KMOD_CONF_OPTS += -Dsbindir=bin
>>>   else
>>> -KMOD_BIN_PATH = ../bin/kmod
>>> -KMOD_SBIN_DIR = sbin
>>> +KMOD_CONF_OPTS += -Dsbindir=sbin
>>>   endif
>>>   else
>>> -KMOD_BIN_PATH = ../usr/bin/kmod
>>> -KMOD_SBIN_DIR = sbin
>>> +KMOD_CONF_OPTS += -Dsbindir=/sbin
>>>   endif
>>
>> Is the bindir/sbindir logic still required actually? I'd have hoped 
>> that meson does this correctly on it's own (afaict these are built-in 
>> meson flags, that supposedly are also filled in with some sensible 
>> default?)
>>
>> Have you tested removing this altogether?
> 
> I don't see any merged-usr (or /usr/bin) handling in pkg-meson.mk. Which 
> makes sense: Almost all packages should install to /usr even without 
> merged-usr, so packages that need to install to /sbin or /bin will need 
> to override.
> 
> We could probably remove the BR2_ROOTFS_MERGED_BIN=y case (but I haven't 
> tested that), because with /usr/sbin as a symlink to /usr/bin the 
> difference shouldn't matter. Makes me wonder why it was originally added 
> though, because the symlinks haven't changed.

Yann, maybe you have some input here?

In general, this is a bit hard to grasp from just reviewing the .mk file 
without building different variations of this, so uhm, what symlnks are 
we trying to create from where to where and why?
> I have tested with and without BR2_ROOTFS_MERGED_USR=y, to get the 
> symlinks in /sbin with BR2_ROOTFS_MERGED_USR=n as before we need - 
> Dsbindir=/sbin (the Meson default is ${prefix}/sbin).
> 
> Whether that makes sense with the kmod binary in /usr/bin is a different 
> question: If /usr is on a separate partition (the ancient reason for the 
> split), the symlinks will be broken until that is mounted. I simply kept 
> the same behavior as before. If placing the symlinks in /usr/sbin in 
> builds with BR2_ROOTFS_MERGED_USR=n is fine, we can remove this whole 
> mess of conditionals. :-)

That would be nice (mostly because I still don't really follow what's 
going on), but could probably come as a separate patch later as well.

> 
> Best regards,
> Fiona
> 
Best,
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Yann E. MORIN via buildroot]

Marcus, Fiona, All,

On 2026-05-01 00:22 +0200, Marcus Hoffmann spake thusly:
[--SNIP--]
> > > Is the bindir/sbindir logic still required actually?
[--SNIP--]
> Yann, maybe you have some input here?
[--SNIP--]
> In general, this is a bit hard to grasp from just reviewing the .mk file
> without building different variations of this, so uhm, what symlnks are we
> trying to create from where to where and why?

The reason why we care about all this mess, is that busybox does
install its tools (lsmod, insmod et al.) if they do not already exist
(the 'install-noclobber' install rule in busybox), so we have to have
those exist in the place busybox would otherwise install its owns.

Otherwise, we'd end up with, e.g.:

    /bin/busybox
    /usr/bin/kmod       <- the real stuff
    /usr/bin/lsmod      <- symlink to busybox
    /usr/sbin/lsmod     <- symlink to kmod

And then, depending on PATH, one may not get the lsmod one expects.
Hence all this dance with the symlinks...

Tis was introduced in 78f5ac2908b3 (kmod: add option to install module
utilities), at a time when individual packages would depend on busybox
to ensure they would "win over busybox", but the comment about the above
was removed in 273f23a45252 (package/busybox: invert dependency with
kmod) when we switched the dependency over, to avoid having packages
replace files from a previously package (in the hope to have a clean
PPD build).

I agree that the handlng is not optimal, but mostly we're comment
explaining the reason for this dance is missing.

> > Whether that makes sense with the kmod binary in /usr/bin is a different
> > question: If /usr is on a separate partition (the ancient reason for the
> > split), the symlinks will be broken until that is mounted. I simply kept
> > the same behavior as before. If placing the symlinks in /usr/sbin in
> > builds with BR2_ROOTFS_MERGED_USR=n is fine, we can remove this whole
> > mess of conditionals. :-)

Check where busybox installs its own symlinks/hardlinks/scripts before
you drop the symlink dance.

As for /usr on a separate partition, I think this is completely ruled
out for the merged-usr case anyway. With unmerged-usr, I am not sure
Buildroot ever officially supported this anyway: as you point out, the
kmod binary is in usr, so usr-on-a-separate-partition-with-kmod never
worked since at least 2012, when 78f5ac2908b3 was introduced...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Fiona Klute via buildroot]

Hi Yann, Marcus, everyone!

Am 01.05.26 um 09:29 schrieb Yann E. MORIN:
> Marcus, Fiona, All,
> 
> On 2026-05-01 00:22 +0200, Marcus Hoffmann spake thusly:
> [--SNIP--]
>>>> Is the bindir/sbindir logic still required actually?
> [--SNIP--]
>> Yann, maybe you have some input here?
> [--SNIP--]
>> In general, this is a bit hard to grasp from just reviewing the .mk file
>> without building different variations of this, so uhm, what symlnks are we
>> trying to create from where to where and why?
> 
> The reason why we care about all this mess, is that busybox does
> install its tools (lsmod, insmod et al.) if they do not already exist
> (the 'install-noclobber' install rule in busybox), so we have to have
> those exist in the place busybox would otherwise install its owns.
> 
> Otherwise, we'd end up with, e.g.:
> 
>      /bin/busybox
>      /usr/bin/kmod       <- the real stuff
>      /usr/bin/lsmod      <- symlink to busybox
>      /usr/sbin/lsmod     <- symlink to kmod
> 
> And then, depending on PATH, one may not get the lsmod one expects.
> Hence all this dance with the symlinks...
> 
> Tis was introduced in 78f5ac2908b3 (kmod: add option to install module
> utilities), at a time when individual packages would depend on busybox
> to ensure they would "win over busybox", but the comment about the above
> was removed in 273f23a45252 (package/busybox: invert dependency with
> kmod) when we switched the dependency over, to avoid having packages
> replace files from a previously package (in the hope to have a clean
> PPD build).
> 
> I agree that the handlng is not optimal, but mostly we're comment
> explaining the reason for this dance is missing.

Thank you, that helps! With that reason we should be able to simplify 
the dance to:

ifeq ($(BR2_ROOTFS_MERGED_USR),)
KMOD_CONF_OPTS += -Dsbindir=/sbin
endif

Busybox places its symlinks in /sbin, so in the non-merged case we need 
to do the same in kmod. In the merged-usr case Busybox will follow the 
/sbin -> /usr/sbin symlink, which matches the kmod default. And in the 
merged-bin case both will follow the /usr/sbin -> /usr/bin symlink. :-)

I wish all packages were that well behaved, I had a very annoying 
discovery in eudev while testing the merged-bin case, where it was 
clobbering its own udevadm binary [1].

>>> Whether that makes sense with the kmod binary in /usr/bin is a different
>>> question: If /usr is on a separate partition (the ancient reason for the
>>> split), the symlinks will be broken until that is mounted. I simply kept
>>> the same behavior as before. If placing the symlinks in /usr/sbin in
>>> builds with BR2_ROOTFS_MERGED_USR=n is fine, we can remove this whole
>>> mess of conditionals. :-)
> 
> Check where busybox installs its own symlinks/hardlinks/scripts before
> you drop the symlink dance.
> 
> As for /usr on a separate partition, I think this is completely ruled
> out for the merged-usr case anyway. With unmerged-usr, I am not sure
> Buildroot ever officially supported this anyway: as you point out, the
> kmod binary is in usr, so usr-on-a-separate-partition-with-kmod never
> worked since at least 2012, when 78f5ac2908b3 was introduced...

Okay, if nobody saw that as a problem since we can probably leave it 
as-is. :-)

Best regards,
Fiona

[1] 
https://patchwork.ozlabs.org/project/buildroot/patch/20260501002320.1761716-3-fiona.klute@gmx.de/
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 4/5] package/kmod: switch to Meson build

[Marcus Hoffmann via buildroot]

Hi Fiona, Yann,

On 5/1/26 13:15, Fiona Klute wrote:
> Hi Yann, Marcus, everyone!
> 
> [...]
>>
>> The reason why we care about all this mess, is that busybox does
>> install its tools (lsmod, insmod et al.) if they do not already exist
>> (the 'install-noclobber' install rule in busybox), so we have to have
>> those exist in the place busybox would otherwise install its owns.
>>
>> Otherwise, we'd end up with, e.g.:
>>
>>      /bin/busybox
>>      /usr/bin/kmod       <- the real stuff
>>      /usr/bin/lsmod      <- symlink to busybox
>>      /usr/sbin/lsmod     <- symlink to kmod
>>
>> And then, depending on PATH, one may not get the lsmod one expects.
>> Hence all this dance with the symlinks...
>>
>> Tis was introduced in 78f5ac2908b3 (kmod: add option to install module
>> utilities), at a time when individual packages would depend on busybox
>> to ensure they would "win over busybox", but the comment about the above
>> was removed in 273f23a45252 (package/busybox: invert dependency with
>> kmod) when we switched the dependency over, to avoid having packages
>> replace files from a previously package (in the hope to have a clean
>> PPD build).
>>
>> I agree that the handlng is not optimal, but mostly we're comment
>> explaining the reason for this dance is missing.
> 
> Thank you, that helps! With that reason we should be able to simplify 
> the dance to:
> 
> ifeq ($(BR2_ROOTFS_MERGED_USR),)
> KMOD_CONF_OPTS += -Dsbindir=/sbin
> endif
> 
> Busybox places its symlinks in /sbin, so in the non-merged case we need 
> to do the same in kmod. In the merged-usr case Busybox will follow the / 
> sbin -> /usr/sbin symlink, which matches the kmod default. And in the 
> merged-bin case both will follow the /usr/sbin -> /usr/bin symlink. :-)


I added a bit more detail about this in the commit message and applied 
your v2 series, thanks! (And thanks Yann for the explanation!)

> 
> I wish all packages were that well behaved, I had a very annoying 
> discovery in eudev while testing the merged-bin case, where it was 
> clobbering its own udevadm binary [1].
> 

Best,
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

[Buildroot] [PATCH 5/5] package/kmod: enable dlopen() for compression libraries (if any)

[Fiona Klute via buildroot]

With dlopen() enabled, kmod will load compression libraries only if
actually needed (loading compressed modules into the kernel does not
if the kernel can handle decompression, depending on its
configuration), and only the needed one.

Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
---
 package/kmod/kmod.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
index e1f713dc01..0afcad0d48 100644
--- a/package/kmod/kmod.mk
+++ b/package/kmod/kmod.mk
@@ -28,6 +28,10 @@ endif
 
 KMOD_CONF_OPTS += -Dfishcompletiondir=no -Dzshcompletiondir=no
 
+# load compression libraries (if any are enabled below) as needed
+# using dlopen()
+KMOD_CONF_OPTS += -Ddlopen=all
+
 ifeq ($(BR2_PACKAGE_ZLIB),y)
 KMOD_DEPENDENCIES += zlib
 KMOD_CONF_OPTS += -Dzlib=enabled
-- 
2.53.0

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 5/5] package/kmod: enable dlopen() for compression libraries (if any)

[Marcus Hoffmann via buildroot]

Hi Fiona,

On 4/25/26 10:56, Fiona Klute via buildroot wrote:
> With dlopen() enabled, kmod will load compression libraries only if
> actually needed (loading compressed modules into the kernel does not
> if the kernel can handle decompression, depending on its
> configuration), and only the needed one.

I don't think this is covered as part of the existing kmod test, right?
Could we add a test covering loading compressed modules without too much 
effort? There's probably a lot of possible variations here (kernel can 
load compressed modules on it's own, or not, and the various compression 
algorithms) but maybe some base functionality that this still works with 
this change can be covered by a test?

> 
> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
> ---
>   package/kmod/kmod.mk | 4 ++++
>   1 file changed, 4 insertions(+)
> 
> diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
> index e1f713dc01..0afcad0d48 100644
> --- a/package/kmod/kmod.mk
> +++ b/package/kmod/kmod.mk
> @@ -28,6 +28,10 @@ endif
>   
>   KMOD_CONF_OPTS += -Dfishcompletiondir=no -Dzshcompletiondir=no
>   
> +# load compression libraries (if any are enabled below) as needed
> +# using dlopen()
> +KMOD_CONF_OPTS += -Ddlopen=all
> +
>   ifeq ($(BR2_PACKAGE_ZLIB),y)
>   KMOD_DEPENDENCIES += zlib
>   KMOD_CONF_OPTS += -Dzlib=enabled

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 5/5] package/kmod: enable dlopen() for compression libraries (if any)

[Fiona Klute via buildroot]

Hi Marcus!

Am 30.04.26 um 14:41 schrieb Marcus Hoffmann:
> Hi Fiona,
> 
> On 4/25/26 10:56, Fiona Klute via buildroot wrote:
>> With dlopen() enabled, kmod will load compression libraries only if
>> actually needed (loading compressed modules into the kernel does not
>> if the kernel can handle decompression, depending on its
>> configuration), and only the needed one.
> 
> I don't think this is covered as part of the existing kmod test, right?
> Could we add a test covering loading compressed modules without too much 
> effort? There's probably a lot of possible variations here (kernel can 
> load compressed modules on it's own, or not, and the various compression 
> algorithms) but maybe some base functionality that this still works with 
> this change can be covered by a test?

The test already builds its own kernel, so I suppose we could extend the 
kernel config to enable CONFIG_MODULE_COMPRESS=y, 
CONFIG_MODULE_COMPRESS_ALL=y but leave CONFIG_MODULE_DECOMPRESS=n (so 
kernel modules are compressed during build, but the kernel does not 
support decompression). That way kmod would have to handle decompression 
for the test to pass (might need enabling the right library package, too).

What do you think of that?

Best regards,
Fiona

> 
>>
>> Signed-off-by: Fiona Klute <fiona.klute@gmx.de>
>> ---
>>   package/kmod/kmod.mk | 4 ++++
>>   1 file changed, 4 insertions(+)
>>
>> diff --git a/package/kmod/kmod.mk b/package/kmod/kmod.mk
>> index e1f713dc01..0afcad0d48 100644
>> --- a/package/kmod/kmod.mk
>> +++ b/package/kmod/kmod.mk
>> @@ -28,6 +28,10 @@ endif
>>   KMOD_CONF_OPTS += -Dfishcompletiondir=no -Dzshcompletiondir=no
>> +# load compression libraries (if any are enabled below) as needed
>> +# using dlopen()
>> +KMOD_CONF_OPTS += -Ddlopen=all
>> +
>>   ifeq ($(BR2_PACKAGE_ZLIB),y)
>>   KMOD_DEPENDENCIES += zlib
>>   KMOD_CONF_OPTS += -Dzlib=enabled
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 5/5] package/kmod: enable dlopen() for compression libraries (if any)

[Marcus Hoffmann via buildroot]

Hi Fiona,

On 4/30/26 15:57, Fiona Klute via buildroot wrote:
> Hi Marcus!
> 
> Am 30.04.26 um 14:41 schrieb Marcus Hoffmann:
>> Hi Fiona,
>>
[...]
>>
>> I don't think this is covered as part of the existing kmod test, right?
>> Could we add a test covering loading compressed modules without too 
>> much effort? There's probably a lot of possible variations here 
>> (kernel can load compressed modules on it's own, or not, and the 
>> various compression algorithms) but maybe some base functionality that 
>> this still works with this change can be covered by a test?
> 
> The test already builds its own kernel, so I suppose we could extend the 
> kernel config to enable CONFIG_MODULE_COMPRESS=y, 
> CONFIG_MODULE_COMPRESS_ALL=y but leave CONFIG_MODULE_DECOMPRESS=n (so 
> kernel modules are compressed during build, but the kernel does not 
> support decompression). That way kmod would have to handle decompression 
> for the test to pass (might need enabling the right library package, too).
> 
> What do you think of that?

Sounds good!

> 
> Best regards,
> Fiona
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH 0/5] package/kmod version 34 and Meson build

[Marcus Hoffmann via buildroot]

Hi Fiona,

On 4/25/26 10:56, Fiona Klute via buildroot wrote:
> Hi everyone,
> 
> this series updates package/kmod to 34.2, and switches it to the new
> Meson build. The upstream changelog for 34 states the old Autotools
> build will be removed with the next major version. I've structured the
> series to switch step by step:
> 
> 1: bump the version (should be backportable, if stable maintainers see
>     the need)
> 2 & 3: tidy up to prepare for build system switch

I applied this until here for now, thanks for the well prepared series! :)

See my replies to the other two patches for some clarifying questions.

> 4: do the build system switch
> 5: enable the new dlopen feature for compression libraries (if any)
> 
> Best regards,
> Fiona

Best,
Marcus
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot