unable to compile krunkit with current main branch of libkrun

[benoitf]

following libkrun/libkrun#735 (review)

creating the issue there:

krunkit fails to build against libkrun main branch

Problem

krunkit cannot compile against libkrun's main branch due to a removed API symbol: krun_set_console_output.

The linker error:

Undefined symbols for architecture arm64:
"_krun_set_console_output", referenced from:
_$LT$krunkit..virtio..VirtioDeviceConfig$u20$as$u20$krunkit..virtio..KrunContextSet$GT$::krun_ctx_set::h71bc32d8d6465b25

Root Cause

libkrun commit ce4146d ("lib: remove krun_disable_implicit_console, krun_set_console_output, and implicit console") removed krun_set_console_output from
the library. This function was gated behind #[cfg(feature = "aws-nitro")] and its dependencies are Linux-only (target.'cfg(target_os = "linux")' in Cargo.toml), so it could never actually work on macOS.

However, krunkit unconditionally declares and calls it in src/virtio.rs:

• extern declaration (line 56): fn krun_set_console_output(ctx_id: u32, c_filepath: *const c_char) -> i32;
• usage in SerialConfig::krun_ctx_set() (lines 248-259): calls krun_set_console_output to redirect console output to a virtio-serial log file

Additional Notes

• Building against stable-1.19.x works fine — that branch still exports the symbol.
• libkrun must also be built with BLK=1 NET=1 flags to export krun_add_disk2, krun_add_net_unixgram, and krun_add_net_unixstream, which are behind cargo feature gates disabled by default.
• libkrun main also removed implicit vsock creation (commit de84d01 "lib: remove krun_disable_implicit_vsock and implicit vsock creation"), requiring an
  explicit krun_add_vsock() call before krun_add_vsock_port2(). krunkit does not currently make this call.

Suggested Fix

1. Remove krun_set_console_output from the extern "C" block in src/virtio.rs
2. Gate SerialConfig::krun_ctx_set() by platform:
   • #[cfg(target_os = "macos")]: log a warning and return Ok(()) (aws-nitro is Linux-only)
   • #[cfg(not(target_os = "macos"))]: keep the current implementation with a local extern block
3. Add a krun_add_vsock(ctx_id, 0) call in src/context.rs before configuring vsock ports, to support libkrun versions that removed implicit vsock

[tylerfanelli]

Thanks for the submission @benoitf.

Suggested Fix

1. Remove `krun_set_console_output` from the `extern "C"` block in `src/virtio.rs`

From what I remember, we replaced the console output API with something else, but still used it with AWS nitro, so essentially this may a no-op on non-nitro? If so, we can probably just remove it.

@jakecorrenti wdyt?

[jakecorrenti]

Yeah, we can remove the krun_set_console_output, and any other implicit resource creation APIs, since they're deprecated. There's no point in keeping them around.

I think that if we want to follow suit with the changes to libkrun to avoid implicit resource creation, we could add a new cmdline option to configure a virtio-output device. From there, we would use the krun_add_{virtio | serial}_console_default which would take fds for input, output, and err.

Or, we could continue with the implicit console creation and re-create the behavior with the API I mentioned above.

@benoitf friendly reminder, though, that since we're developing for 2.0 on the libkrun side, breakages are expected. We will of course get around to fixing them, but it's to be expected until the release comes out and everything is stable.

[benoitf]

@benoitf friendly reminder, though, that since we're developing for 2.0 on the libkrun side, breakages are expected. We will of course get around to fixing them, but it's to be expected until the release comes out and everything is stable.

yes no issue there, you asked me to file the issue. I'm more interested in having a bugfix release of krunkit included in podman v6/libkrun, it could even be based on 1.19.x I'm also fine

[slp]

I think krunkit should target stable-1.19.x until 2.0 is released.

yes no issue there, you asked me to file the issue. I'm more interested in having a bugfix release of krunkit included in podman v6/libkrun, it could even be based on 1.19.x I'm also fine

I can create a package for podman. Is stable-1.19.0 enough or are you interested in some PR in particular?

[benoitf]

I'm interested in libkrun/libkrun#734

I've created a backport to 1.19.x there libkrun/libkrun#735

(but it's still under review)

I think krunkit should target stable-1.19.x until 2.0 is released.

yes no issue there, you asked me to file the issue. I'm more interested in having a bugfix release of krunkit included in podman v6/libkrun, it could even be based on 1.19.x I'm also fine

I can create a package for podman. Is stable-1.19.0 enough or are you interested in some PR in particular?

[slp]

I'm interested in libkrun/libkrun#734

I've created a backport to 1.19.x there libkrun/libkrun#735

Ack. Let's get them in and release a 1.19.1.