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

Support MinGW as a wasmtime target #1535

Closed
alexcrichton opened this issue Apr 17, 2020 · 5 comments · Fixed by #1580
Closed

Support MinGW as a wasmtime target #1535

alexcrichton opened this issue Apr 17, 2020 · 5 comments · Fixed by #1580
Labels
wasmtime Issues about wasmtime that don't fall into another label

Comments

@alexcrichton
Copy link
Member

It looks like Go at least only supports MinGW as a toolchain to link with, but wasmtiem does not currently have MinGW support. If we'd like to support Windows support for Wasmtime in Go I think we'll need to add a MinGW target as well as CI/releases for it.
@alexcrichton alexcrichton added the wasmtime Issues about wasmtime that don't fall into another label label Apr 17, 2020
@alexcrichton alexcrichton mentioned this issue Apr 17, 2020
Closed
@tschneidereit
Copy link
Member

Do you know how complicated that would be initially—and how much of a maintenance burden it'd be on an ongoing basis? If neither is a concern, this makes sense to me. Otherwise, I think we should let the be driven by use cases.

@tschneidereit
Copy link
Member

Ah, I now see the wasmtime-go issue. I guess the question is how many people will want to run Go programs on Windows, which I don't have a good handle on.

@alexcrichton
Copy link
Member Author

Oh sorry I should have clarified, but I definitely agree that we should let use cases and difficulty of implementation guide this in terms of priorities. I don't think it's clear how motivated this is right now (I don't know how often it'd be wanted on Go for Windows). I suspect this would be relatively difficult because of stack unwinding, but I might give this a go later today and see if it "trivially works" or "trivially doesn't work". Basically I think it's probably worth a little bit of effort to see how much effort it would take for us to support this.

@tschneidereit
Copy link
Member

That makes a lot of sense to me, yes. Thank you for the clarification!

@alexcrichton
Copy link
Member Author

Turns out that with #1490 all tests pass. I think there's probably some difference in how big the stack is when a segfault comes in which causes issues today, but once #1490 lands I can look into adding this to CI. Don't think it'll be too too hard!

alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Apr 22, 2020
@alexcrichton
Add a MinGW release to our CI
85b27b6 
This commit extends our CI to produce release artifacts for the
x86_64-pc-windows-gnu target. This was originally motivate by the [go
extension] where it looks like the Go toolchain primarily interoperates
with MinGW, not with MSVC natively.

The support here turned out to be quite trivial, largely just adding the
configuration to make the release. I don't think we should necessarily
commit to this being a primary platform for Wasmtime at this time
though. If the support here regresses in the future for a
difficult-to-fix reason I think it would be fine to back out the
platform at least temporarily.

Note that this does not add a full test suite for the MinGW target, only
a release builder. This release builder does run tests, but not with
full debug assertions enabled.

[go extension]: bytecodealliance/wasmtime-go#3

Closes bytecodealliance#1535
@alexcrichton alexcrichton mentioned this issue Apr 22, 2020
Merged
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Apr 22, 2020
@alexcrichton
Add a MinGW release to our CI
aa7f175 
This commit extends our CI to produce release artifacts for the
x86_64-pc-windows-gnu target. This was originally motivate by the [go
extension] where it looks like the Go toolchain primarily interoperates
with MinGW, not with MSVC natively.

The support here turned out to be quite trivial, largely just adding the
configuration to make the release. I don't think we should necessarily
commit to this being a primary platform for Wasmtime at this time
though. If the support here regresses in the future for a
difficult-to-fix reason I think it would be fine to back out the
platform at least temporarily.

Note that this does not add a full test suite for the MinGW target, only
a release builder. This release builder does run tests, but not with
full debug assertions enabled.

[go extension]: bytecodealliance/wasmtime-go#3

Closes bytecodealliance#1535
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
wasmtime Issues about wasmtime that don't fall into another label
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Add a MinGW release to our CI alexcrichton/wasmtime
2 participants
@tschneidereit @alexcrichton