Stream: git-wasmtime

Topic: wasmtime / issue #4957 Broken Windows builds via 0.40 sin...


view this post on Zulip Wasmtime GitHub notifications bot (Sep 25 2022 at 13:48):

pinkforest edited issue #4957:

Problem now is that anyone using 0.40 e.g. via wasi-common will get 0.25 cap-std

         ├── wasi-common v0.40.0
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.2
               ├── cap-primitives v0.25.2

And therefore incompat cap-primitives in Windows when using stable > 1.64.0 rust stable that has sealed the FileTypeExt trait

By doing nothing this still works on at least unix but Windows is now broken on it's default state doing nothing on rust stable 1.64

wasi-common < 1 Windows builds broken

I would have to bump everything to ^1 atm from 0.40

Root cause

This was seen earlier in https://github.com/bytecodealliance/cap-std/issues/275 via nightly broken

A trait was sealed that then broke the builds via [cap-primitives](https://crates.io/crates/cap-primitives)

I documented my find originally: https://github.com/rust-lang/rust/issues/102260

Work/Around - Works for Windows Only probably ?

There is a work/around here: https://github.com/bytecodealliance/wasmtime/issues/4936

The work/around patch is in cap-std commits:
git diff de739728299408dfce96315b3c82a14c952a6cf3 949f251bccbb84513fe81a427a46864c1e8ad82c

Work/Around does not work for unix

Work/around in turn seems to break unix builds as described here: https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

Ideal Resolution ?

Could we address so this builds for both Windows and Linux / unix via 0.40 ?

Perhaps we could also bump wasi-common so it bumps up to 0.26 that whole chain for cap-primitives ?

But I think the build errors need to be sorted for unix as I suspect the patch has broken all unix now ? https://github.com/bytecodealliance/wasmtime/issues/4936#issuecomment-1257183650

This is how I bumped my :lock: to 0.40.1 - released 25 days ago or so

Additional attempts

I also tried quickly with 0.40.1 wasi-common but it still brings 0.25 tree

$ cargo update -p wasmtime-wasi --precise 0.40.1

    Updating crates.io index
    Updating cranelift-bforest v0.87.0 -> v0.87.1
    Updating cranelift-codegen v0.87.0 -> v0.87.1
    Updating cranelift-codegen-meta v0.87.0 -> v0.87.1
    Updating cranelift-codegen-shared v0.87.0 -> v0.87.1
    Updating cranelift-entity v0.87.0 -> v0.87.1
    Updating cranelift-frontend v0.87.0 -> v0.87.1
    Updating cranelift-isle v0.87.0 -> v0.87.1
    Updating cranelift-native v0.87.0 -> v0.87.1
    Updating cranelift-wasm v0.87.0 -> v0.87.1
    Updating wasi-cap-std-sync v0.40.0 -> v0.40.1
    Updating wasi-common v0.40.0 -> v0.40.1
    Updating wasmtime v0.40.0 -> v0.40.1
    Updating wasmtime-asm-macros v0.40.0 -> v0.40.1
    Updating wasmtime-cache v0.40.0 -> v0.40.1
    Updating wasmtime-cranelift v0.40.0 -> v0.40.1
    Updating wasmtime-environ v0.40.0 -> v0.40.1
    Updating wasmtime-fiber v0.40.0 -> v0.40.1
    Updating wasmtime-jit v0.40.0 -> v0.40.1
    Updating wasmtime-jit-debug v0.40.0 -> v0.40.1
    Updating wasmtime-runtime v0.40.0 -> v0.40.1
    Updating wasmtime-types v0.40.0 -> v0.40.1
    Updating wasmtime-wasi v0.40.0 -> v0.40.1
    Updating wiggle v0.40.0 -> v0.40.1
    Updating wiggle-generate v0.40.0 -> v0.40.1
    Updating wiggle-macro v0.40.0 -> v0.40.1

And my dependency tree gets 0.25 on which I had to apply the branch-patch

         ├── wasi-common v0.40.1
            ├── cap-rand v0.25.2
            ├── cap-std v0.25.3
               ├── cap-primitives v0.25.3

I originally went down the :hole: https://github.com/bytecodealliance/cap-std/issues/270#issuecomment-1257176470

Refs

https://github.com/lunatic-solutions/lunatic/issues/136 <-- Downstream crate impacted
https://github.com/rust-lang/rust/issues/102260 <-- Went finding out what happened in std first - did not find these issues here
https://github.com/bytecodealliance/cap-std/issues/275 <-- I went first
https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.E2.9C.94.20.23102260.20Sealed.20Windows.20FileTypeExt/near/300637075 <-- Chris Denton was helpful to point the above issue

Cheers


Last updated: Oct 23 2024 at 20:03 UTC