Unable to compile `libkrun` post v1.16.0 as cargo dependency - transient dependency version mismatches

[drahnr]

Any release post v1.16.0 exhibits multiple versions of vm-memory being used and consequently missing trait bound implementations. When linking libkrun = { git = "https://github.com/containers/libkrun", features = ["blk", "net", "input", "gpu"], tag = "v1.19.0" }.

[jakecorrenti]

Hi @drahnr, thank you for filing this issue! I'm able to reproduce and taking a look at it now

[mtjhrc]

@jakecorrenti
I think this was the blocker for updating vm-memory everywhere: rust-vmm/linux-loader#229
@d-e-s-o

It's now merged, so I suppose we just need a release.

[jakecorrenti]

@jakecorrenti I think this was the blocker for updating vm-memory everywhere: rust-vmm/linux-loader#229 @d-e-s-o

It's now merged, so I suppose we just need a release.

it seems like they still need to cut a release for that commit to be included, though. I'll file an issue to see if they can make a release.

[jakecorrenti]

rust-vmm/linux-loader#238

[jakecorrenti]

we're also going to need to wait for this in order to bump everything to 0.18 rust-vmm/vhost#348

[d-e-s-o]

Any release post v1.16.0 exhibits multiple versions of vm-memory being used and consequently missing trait bound implementations.

Yeah, I hit what sounds like the same problem multiple times. From what I recall the problem really is with vm-memory 0.17.2 (I forgot the details, but I think they re-export a bunch of stuff and that clashes). So to get unblocked I believe you can pin 0.17.1 and that should help resolve things until all the necessary releases are out (e.g., [0]; I recall seeing that being done in one of the repositories here as well but can't find it offhand).

[jakecorrenti]

Any release post v1.16.0 exhibits multiple versions of vm-memory being used and consequently missing trait bound implementations.

Yeah, I hit what sounds like the same problem multiple times. From what I recall the problem really is with vm-memory 0.17.2 (I forgot the details, but I think they re-export a bunch of stuff and that clashes). So to get unblocked I believe you can pin 0.17.1 and that should help resolve things until all the necessary releases are out (e.g., [0]; I recall seeing that being done in one of the repositories here as well but can't find it offhand).

Cargo.lock on main is currently pinned to 0.17.1 and, at least in my testing, that still isn't resolving things

[mtjhrc]

Well I am pretty sure Cargo.lock resolves it. Problem is that @drahnr would need to currently manually edit their Cargo.lock and pin everything to vm-memory 1.17.1. Cargo.lock of rust crates used as libraries is ignored - only the toplevel Cargo.lock matter - which would either be a cdylib in our case or a binary executable.

[drahnr]

@mtjhrc it does not, I just tried libkrun @ v1.19.0 and v1.18.0, neither does work:

   Compiling krun-devices v0.1.0-1.19.0 (https://github.com/libkrun/libkrun?tag=v1.19.0#9932c4b5)
error[E0277]: the trait bound `VolatileSlice<'_>: ImagoAsRef<'_, VolatileSlice<'_, _>>` is not satisfied
    --> /home/bernhard/.cargo/git/checkouts/libkrun-cf282792a97f6e4d/9932c4b/src/devices/src/virtio/file_traits.rs:430:64
     |
 430 |         let (iovec, _guard) = IoVectorMut::from_volatile_slice(bufs);
     |                               -------------------------------- ^^^^ the trait `imago::misc_helpers::ImagoAsRef<'_, vm_memory::volatile_memory::VolatileSlice<'_, _>>` is not implemented for `VolatileSlice<'_>`
     |                               |
     |                               required by a bound introduced by this call
     |
help: the following other types implement trait `imago::misc_helpers::ImagoAsRef<'a, T>`
    --> /home/bernhard/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/imago-0.2.2/src/misc_helpers.rs:63:1
     |
  63 |   impl<'a, T: ?Sized, U: ImagoAsRef<'a, T>> ImagoAsRef<'a, T> for &'a U {
     |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `&'a U` implements `imago::misc_helpers::ImagoAsRef<'a, T>`
...
  70 | / impl<'a, B: vm_memory::bitmap::BitmapSlice> ImagoAsRef<'a, vm_memory::VolatileSlice<'a, B>>
  71 | |     for &'a vm_memory::VolatileSlice<'a, B>
     | |___________________________________________^ `&'a vm_memory::volatile_memory::VolatileSlice<'a, B>` implements `imago::misc_helpers::ImagoAsRef<'a, vm_memory::volatile_memory::VolatileSlice<'a, B>>`
     = note: there are multiple different versions of crate `vm_memory` in the dependency graph
     = help: you can use `cargo tree` to explore your dependency tree
     = note: required for `&VolatileSlice<'_>` to implement `imago::misc_helpers::ImagoAsRef<'_, vm_memory::volatile_memory::VolatileSlice<'_, _>>`
.. more ..

v1.17.0 fails with the known

error: couldn't read `/home/bernhard/.cargo/git/checkouts/libkrun-cf282792a97f6e4d/376f256/src/devices/src/virtio/fs/linux/../../../../../../init/init`: No such file or directory (os error 2)
  --> /home/bernhard/.cargo/git/checkouts/libkrun-cf282792a97f6e4d/376f256/src/devices/src/virtio/fs/linux/passthrough.rs:36:29
   |
36 | static INIT_BINARY: &[u8] = include_bytes!("../../../../../../init/init");
   |                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

using

libkrun = { git = "https://github.com/libkrun/libkrun", features = ["blk", "net", "input", "gpu"], tag = "v1.17.0" }
vm-memory = "=0.17.1" # as suggested
imago = "=0.2.2" # needed to avoid the 0.18 vm-memory re-export in 0.18.0

[drahnr]

The issues are identical with imago = "=0.2.3"

[drahnr]

The real offender here is

cargo tree -i vm-memory@0.18.0
vm-memory v0.18.0
└── imago v0.2.2
    ├── butterpot v0.1.0 (/media/humpback/projects/konifay/butterpot)
    └── krun-devices v0.1.0-1.19.0 (https://github.com/libkrun/libkrun?tag=v1.19.0#9932c4b5)
        ├── krun-vmm v0.1.0-1.19.0 (https://github.com/libkrun/libkrun?tag=v1.19.0#9932c4b5)
        │   └── libkrun v1.19.0 (https://github.com/libkrun/libkrun?tag=v1.19.0#9932c4b5)
        │       └── butterpot v0.1.0 (/media/humpback/projects/konifay/butterpot)
        └── libkrun v1.19.0 (https://github.com/libkrun/libkrun?tag=v1.19.0#9932c4b5) (*)

so I'd have to patch that to re-export 0.17.1 of vm-memory.

[jakecorrenti]

#728

[mtjhrc]

@mtjhrc it does not, I just tried libkrun @ v1.19.0 and v1.18.0, neither does work:

I meant edit the Cargo.lock (not Cargo.toml) manually to force it to resolve to 1.17.1 as a temporary fix/hack in the mean time. You can make the dependencies section of all crates point to the same "vm-memory 1.17.1". Yes this is sketchy and one isn't supposed to edit that file normally but it fixes it. (But if you are building a library crate then the downstream consumers also have to fix it in their Cargo.lock which is horrible).

But anyways hopefully we can get this resolved properly soon.