Skip to content

MSG_PEEK and MSG_DONTWAIT not declared by package syscall with GOOS=js GOARCH=ecmascript #1141

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
Closed
tomconnell-wf opened this issue Aug 17, 2022 · 1 comment
Closed

MSG_PEEK and MSG_DONTWAIT not declared by package syscall with GOOS=js GOARCH=ecmascript #1141

tomconnell-wf opened this issue Aug 17, 2022 · 1 comment
Labels
question

Comments

@tomconnell-wf
Copy link
Contributor

I'm trying out our build using Go 1.18.5 and gopherjs master. I'm using GOOS=js GOARCH=ecmascript

The build fails because some dependencies are attempting to use syscall.MSG_PEEK and syscall.MSG_DONTWAIT. Part of me thinks we are using dependencies that really shouldn't be included in a GopherJS build, but I wanted to check. If these are legit usages, then it seems like some syscall stuff needs generated for GOOS=js GOARCH=ecmascript. We're hacking around it by slapping in build tags in vendored dependencies files to hide them from the build. I probably don't have to say how nervous that makes me. 😨

Looking at this makes me think that there is missing tag/target generation.

I understand that's std library stuff, but I wanted to bring it up here to get perspective on it. If there does need to be additional targets/tags generated, it seems like it would be good to have you all involved in asking for it.
@nevkontakte
Copy link
Member

I'm afraid this is working as intended. One of the changes that have landed in the GopherJS 1.18 is #1111, which changed how we build standard library. Specifically, the standard library is now always build as if GOOS=js GOARCH=wasm, which changes the set of constants available in the syscall package to what would be available to Go WebAssembly code. https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md has a bit more detail on the current state of affairs.

Worth noting that if you run GopherJS code in the, those syscalls would have never worked, so they probably are referenced by some dead code (at least for your use case). The best solution I may offer is sending patches to your upstream dependency to make them more compatible. In general //go:build js should work for both GopherJS and WebAssembly builds.

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

No branches or pull requests
2 participants
@nevkontakte @tomconnell-wf