Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Failed to build wasmtime in Windows 10 #122

Closed
yushulx opened this issue Apr 25, 2019 · 2 comments
Closed

Failed to build wasmtime in Windows 10 #122

yushulx opened this issue Apr 25, 2019 · 2 comments

Comments

@yushulx
Copy link

yushulx commented Apr 25, 2019

I built the source code in Windows 10:

cargo build --release

Here is the error message:

Done Building Project "G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj" (default targets) -- FAILED.
Done Building Project "G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\ALL_BUILD.vcxproj" (default targets) -- FAILED.
Done Building Project "G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\install.vcxproj" (default targets) -- FAILED.

Build FAILED.

"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\install.vcxproj" (default target) (1) ->
"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\ALL_BUILD.vcxproj" (default target) (3) ->
"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj" (default target) (4) ->
(ClCompile target) ->
  g:\wasi\wasmtime\wasmtime-wasi\sandboxed-system-primitives\src\str.c(22): warning C4047: 'initializing': 'char *' differs in levels of indirection from 'int' [G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj]


"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\install.vcxproj" (default target) (1) ->
"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\ALL_BUILD.vcxproj" (default target) (3) ->
"G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj" (default target) (4) ->
(ClCompile target) ->
  g:\wasi\wasmtime\wasmtime-wasi\sandboxed-system-primitives\src\posix.c(16): fatal error C1083: Cannot open include file: 'sys/ioctl.h': No such file or directory [G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj]
  g:\wasi\wasmtime\wasmtime-wasi\sandboxed-system-primitives\src\random.c(15): fatal error C1083: Cannot open include file: 'pthread.h': No such file or directory [G:\wasi\wasmtime\target\release\build\wasmtime-wasi-628aff801f2e5951\out\build\SandboxedSystemPrimitives.vcxproj]

    1 Warning(s)
    2 Error(s)
@yushulx yushulx changed the title Failed to build wasmtime in Windows Failed to build wasmtime in Windows 10 Apr 25, 2019
@sunfishcode
Copy link
Member

Wasmtime doesn't yet support Windows. It's a goal to do so, though we haven't yet gotten to it. If anyone is interested in helping with this, I'd be happy to mentor!

@tschneidereit
Copy link
Member

Building on Windows should work now, so I'm closing this. Please reopen if you're still running into issues.

grishasobol pushed a commit to grishasobol/wasmtime that referenced this issue Nov 29, 2021
@pepyakin
Add no_std support (bytecodealliance#122)
20154c5 
* add default-enabled std feature

* use parity-wasm/std feature only if std is enabled

* drop dependency on std::io

* use hashmap_core instead of std::collections::HashMap

* disable std::error in no_std

* core and alloc all the things

* mention no_std in readme

* add no_std feature and use hashmap_core only on no_std

* rename the no_std feature to core

* drop dependency on byteorder/std

* simplify float impl macro

* remove some trailing whitespace

* use libm for float math in no_std

* add note about no_std panics of libm to readme

* Embed nan-preserving-float crate.

* Add no_std check to the Travis CI config

* add missing dev-dependency
pchickey pushed a commit to pchickey/wasmtime that referenced this issue May 16, 2023
@dicej
Merge pull request bytecodealliance#122 from dicej/nanos-millis
cbca97e 
fix nanosecond->millisecond conversion in `poll_oneoff`
frank-emrich added a commit to frank-emrich/wasmtime that referenced this issue Mar 21, 2024
@frank-emrich
Enable limited stack overflow checks while running inside continuatio…
d6522e2 
…ns (bytecodealliance#136)

Currently, we can overflow the stack while running inside a
continuation, without the runtime having any way of detecting this.
This PR partially rectifies this, by making the existing stack limit
checks that get emitted by cranelift in every wasm function prelude work
correctly while running inside a continuation.

All that was required to enable the stack limit checks was the
following:
1. Stop zero-ing out the `stack_limit` value in `VMRuntimeLimits`
whenever we `resume` a continuation.
2. When creating a continuation, set a reasonable value for the
`stack_limits` value in its `StackLimits` object.

Note that all the required infrastructure to make sure that whenever we
switch stacks, we save and restore the `stack_limits` value inside
`VMRuntimeLimits` and the `StackLimits` object of the involved stacks
was already implemented in bytecodealliance#98 and bytecodealliance#99. In this sense, enabling these
checks is "free": The limits were already checked, but previously using
a limit of 0.

The only remaining question is what the "reasonable value" for the stack
limits value mentioned above is. As discussed in bytecodealliance#122, the stack limit
checks that cranelift emits in function preludes are rather limited, and
these limitations are reflected in the checks that this PR provides:
When entering a wasm function, they check that the current stack pointer
is larger than the `stack_limit` value in `VMRuntimeLimits`. They do not
take into account how much stack space the function itself will occupy.
No stack limit checks are performed when calling a host function.

Thus, this PR defines a config option `wasmfx_red_zone_size`. The idea
is that we define the stack limit as `bottom_of_fiber_stack` +
`wasmfx_red_zone_size`. Thus, the stack checks boil down to the
following:
Whenever we enter a wasm function while inside a continuation, we ensure
that there are at least `wasmfx_red_zone_size` bytes of stack space
left.

I've set the default value for `wasmfx_red_zone_size` to 32k. To get a
rough idea for a sensible value, I determined that a call to the
`fd_write` WASI function occupies ~21k of stack space, and generously
rounded this up to 32k.

**Important**: This means that these stack limit checks are incomplete:
Calling a wasm or host function that occupies more than
`wasmfx_red_zone_size` of stack space may still result in an undetected
stack overflow!
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this issue Oct 9, 2024
@mmcloughlin
isaspec: generate AluRRRShift spec (bytecodealliance#122)
0ba9782 
Generate `AluRRRShift` spec with ASLp.

This is the second example of a spec that relies on symbolic opcodes,
but it's slightly more challenging because the shift amount determines
the size of the symbolic field. Not only that, but the spec cases split
on `shiftop`, which is a struct type. In addition, the `lshl_from_imm64`
spec needed to be fixed.

Updates avanhatt#36 avanhatt#35
Closes bytecodealliance#120
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this issue Oct 23, 2024
@mmcloughlin
isaspec: AluRRR shift opcodes (bytecodealliance#185)
229a714 
Generate specs for the shift opcodes of `AluRRR` instructions.

These had previously been disabled because of an issue with the bitwidth
of shift amounts. That has since been resolved in bytecodealliance#122 so we can enable
them here without issue.

Updates avanhatt#34 avanhatt#35
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this issue Oct 23, 2024
@mmcloughlin @avanhatt
isaspec: AluRRR shift opcodes (bytecodealliance#185)
7b2b067 
Generate specs for the shift opcodes of `AluRRR` instructions.

These had previously been disabled because of an issue with the bitwidth
of shift amounts. That has since been resolved in bytecodealliance#122 so we can enable
them here without issue.

Updates avanhatt#34 avanhatt#35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@tschneidereit @yushulx @sunfishcode