Wasmtime GitHub notifications bot (Jun 12 2021 at 23:28): Wasmtime GitHub notifications bot (Jun 12 2021 at 23:28):cfallin commented on issue #2980:
I'll also note that this depends on darfink/region-rs#8, which was recently added but has not yet been released yet; I'll ping over there to see if they can release a new version to crates.io.
Wasmtime GitHub notifications bot (Jun 12 2021 at 23:43):github-actions[bot] commented on issue #2980:
Subscribe to Label Action
cc @kubkon
<details>
This issue or pull request has been labeled: "wasi"Thus the following users have been cc'd because of the following labels:
- kubkon: wasi
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Jun 14 2021 at 16:17):abrown commented on issue #2980:
@cfallin, I'm interested in why the openvino-sys crate is failing: the way we build it here, it _should_ have no target-specific logic since it uses
libloadingto look for the right libraries. Can you send me the failed build output and I'll try to fix upstream?
Wasmtime GitHub notifications bot (Jun 14 2021 at 16:55):cfallin commented on issue #2980:
@cfallin, I'm interested in why the openvino-sys crate is failing: the way we build it here, it _should_ have no target-specific logic since it uses
libloadingto look for the right libraries. Can you send me the failed build output and I'll try to fix upstream?It's an issue with some platform-specific constants that are defined with
#[cfg(linux)]or similar rather than "all Unix-like platforms", I think:error[E0425]: cannot find value `ENV_LIBRARY_PATH` in this scope --> /home/cfallin/.cargo/registry/src/github.com-1ecc6299db9ec823/openvino-finder-0.3.1/src/lib.rs:44:37 | 44 | if let Some(path) = env::var_os(ENV_LIBRARY_PATH) { | ^^^^^^^^^^^^^^^^ not found in this scope error[E0425]: cannot find value `DEFAULT_INSTALLATION_DIRECTORIES` in this scope --> /home/cfallin/.cargo/registry/src/github.com-1ecc6299db9ec823/openvino-finder-0.3.1/src/lib.rs:54:24 | 54 | for default_dir in DEFAULT_INSTALLATION_DIRECTORIES | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: a constant with a similar name exists: `KNOWN_INSTALLATION_SUBDIRECTORIES`
Wasmtime GitHub notifications bot (Jun 14 2021 at 22:43):sunfishcode commented on issue #2980:
system-interface 0.6.6 and posish 0.6.3 are now available.
Wasmtime GitHub notifications bot (Jun 29 2021 at 00:32):cfallin commented on issue #2980:
@sunfishcode I've updated this now with some spare cycles and I think it might be good for another look, whenever you have the chance! It's still pending a region.rs release but I've pinged over there. I resolved the
libcdependency for now with a C helper, which isn't ideal but is better than a hardcoded constant.There's also some version weirdness where cap-std-* is pulling in two versions of
rustc_version(see cargo-deny CI job); not sure what's going on there.
Wasmtime GitHub notifications bot (Jun 29 2021 at 06:17):cfallin commented on issue #2980:
Updated, thanks! This just depends now on (i) a region-rs release, and (ii) resolution of some multi-crate-version weirdness:
@sunfishcode, it seems that we have:
- system-interface 0.6.6 -> cap-fs-ext 0.13.7 -> unsafe_io 0.6.12 -> rustc_version 0.3.3
- system-interface 0.6.6 -> cap-fs-ext 0.13.7 -> unsafe_io 0.6.12 -> io_lifetimes 0.1.1 -> rustc_version 0.4.0
- system-interface 0.6.6 -> cap-fs-ext 0.13.10 -> rustc_version 0.3.3
- system-interface 0.6.6 -> rustc_version 0.4.0
in general it seems the various cap-std-related crates have inconsistent dependencies on
rustc_version, which is making cargo-deny unhappy -- thoughts? Would it be possible to harmonize everything to 0.4.0?
Wasmtime GitHub notifications bot (Jun 29 2021 at 07:04):cfallin commented on issue #2980:
@alexcrichton PTAL again (with low priority for this unofficial side-project!) re: fibers -- there's some additional flags-setting needed that I hadn't realized before too, as OpenBSD has a special mitigation that requires blessing stack memory in a certain way.
Wasmtime GitHub notifications bot (Jun 29 2021 at 08:55):cfallin commented on issue #2980:
With latest updates, all tests pass in
wasmtimecrate. I had to disable the pooling allocator as well, forMAP_STACK-related reasons. Checking all tests would require me to set up a wasm32-wasi toolchain, which means building rustc from source (whee!), so that's the last of my side-project steam for now.On a slightly less-unofficial note, at some point it would be neat to articulate a tier strategy for platform support; I imagine something like Rust's tier 1/2/3 (tested, compiled, and best-effort respectively?), where OpenBSD is definitely tier 3, but there might be some systems we could include at tier 2 (other BSDs? Linux/musl? macOS/aarch64?) if cross-compilation works.
Wasmtime GitHub notifications bot (Jun 29 2021 at 08:56):cfallin edited a comment on issue #2980:
With latest updates, all tests pass in
wasmtimecrate. I had to disable the pooling allocator as well, forMAP_STACK-related reasons. Checking all tests (our full CI gamut) would require me to set up a wasm32-wasi toolchain, which means building rustc from source (whee!), so that's the last of my side-project steam for now.On a slightly less-unofficial note, at some point it would be neat to articulate a tier strategy for platform support; I imagine something like Rust's tier 1/2/3 (tested, compiled, and best-effort respectively?), where OpenBSD is definitely tier 3, but there might be some systems we could include at tier 2 (other BSDs? Linux/musl? macOS/aarch64?) if cross-compilation works.
Wasmtime GitHub notifications bot (Jul 01 2021 at 01:56):sunfishcode commented on issue #2980:
@cfallin https://github.com/bytecodealliance/wasmtime/pull/3049 updates almost everything to rustc_version 0.4.0, except wasmtime still depends on criterion which depends on cast which depends on rustc_version 0.3.3. I've now submitted https://github.com/japaric/cast.rs/pull/34 to update cast.
Wasmtime GitHub notifications bot (Aug 29 2021 at 18:25):cfallin commented on issue #2980:
I just rebased onto latest
mainand updated to region-rs 3.0.0, which includes a fix for OpenBSD.Unfortunately it looks like new build failures have cropped up in the meantime, this time in
rsix(bytecodealliance/rsix#32). I also had to upgrade my test VM to OpenBSD-current to get Rust 1.54.0 because -stable (currently 6.9) has Rust 1.51.0, which fails to build some other things. (Rustup doesn't support OpenBSD unfortunately so one must use the system package or build from source.)Given the moving target, the fact that we probably won't have a reasonable way to test this on CI, and the fact that we (or at least I) don't really have the time to support another platform beyond "one weekend morning once every few months" (this PR so far), I think I'll go ahead and close this PR. We should definitely reconsider this if/when OpenBSD graduates from tier3 and Rustup adds binaries, and if/when we have a way of adding native GitHub CI runners, at which point someone could run OpenBSD CI.
Until then I'll keep the
wasmtimebinary on my little router as a keepsake from that one golden moment when this PR compiled cleanly. Thanks for the patience, all!
Last updated: Nov 22 2024 at 16:03 UTC