kmod static building

[piyush-jena]

Hi!
The migration of kmod build system to meson no longer allows users to do a static build of kmod. I am using the following patch to do a static build. I was wondering if there's a possibility of merging this to the original code base.

From b5d3e27e19101712bab37695283c2d8bc3960b28 Mon Sep 17 00:00:00 2001
From: Piyush Jena <jepiyush@amazon.com>
Date: Tue, 8 Jul 2025 22:11:12 +0000
Subject: [PATCH] meson: add support for static builds

Signed-off-by: Piyush Jena <jepiyush@amazon.com>
---
 meson.build | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/meson.build b/meson.build
index a0cf675..4b16d6a 100644
--- a/meson.build
+++ b/meson.build
@@ -465,10 +465,16 @@ kmod_sources = files(
   'tools/static-nodes.c',
 )
 
+kmod_link_args = []
+if get_option('default_library') == 'static'
+  kmod_link_args += ['-static']
+endif
+
 kmod = executable(
   'kmod',
   kmod_sources,
   link_with : [libshared, libkmod_internal],
+  link_args : kmod_link_args,
   gnu_symbol_visibility : 'hidden',
   build_by_default : get_option('tools'),
   install : get_option('tools'),
-- 
2.47.1

[lucasdemarchi]

Biggest issue with static linking is about the library, libkmod. It doesn't work because the static library would expose symbols that should be private. As soon as you try to link other tools statically with multiple libraries we will start to see duplicate symbols

The kmod binary could be allowed to be static though. Looking around it doesn't seem meson has a built-in option for that. @evelikov do you know? Otherwise we could allow the user to pass e.g. -Dstatic-tools

[evelikov]

AFAICT the symbol collision can happen in either case - static libkmod or static tools. Personally I don't object to having either/both. The -Dstatic-tools of type bool looks reasonable to me.

What I would love to see is, albeit non-blocking:

• some meson warning when used, highlighting the 1) licensing implications and 2) not officially supported (unless Lucas prefers otherwise)
• an example from open-source project/pipeline that it works without major hacks

[piyush-jena]

Hi @evelikov and @lucasdemarchi !

We are using this code in bottlerocket-os. The PR that added the patch I pasted above is bottlerocket-os/bottlerocket-core-kit #562.

Currently, we are depending on the -Ddefault_library to choose if we want to link statically or dynamically.

If you check the removed code from the PR, you will notice that we were using static builds prior to the move to meson. As the latest change didn't allow this, we created this patch.

I am happy to take suggestions and work towards a solution with you.

[evelikov]

Seems like I've slightly misread @lucasdemarchi question - sorry 😅

I don't see a meson option to for the default linking of binaries - only the library one default_library and the general prefer_static.

@piyush-jena the project is just the example I was looking for. Thank you.

Some step-by-step suggestions - don't need to follow religiously, opt for what makes sense:

• add new option static-tools (defaulting to false) to our meson_options.txt, which when enabled
  • controls the tools' linking mode
  • (from your PR) overrides (see sbindir handling) prefer_static to true
  • (from your PR) adds -all-static to the linker flags
  • (optional) add something alike warning('Using static-tools is not officially supported although patches are welcome ;-)')
  • (optional) add something alike warning('Using static-tools may change the license of the tools, based on the components linked in. CAREFULLY review the respective licenses for more details')

At a glance the option -all-static is required only by libtool which meson does not use. Do you mind double-checking it things work without it?

Warnings are optional and better wording is more than welcome.