Skip to content

GopherJS 1.8-wip: "warning: system calls not available" printed whenever "os" package imported. #583

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
dmitshur opened this issue Feb 9, 2017 · 7 comments
Closed

GopherJS 1.8-wip: "warning: system calls not available" printed whenever "os" package imported. #583

dmitshur opened this issue Feb 9, 2017 · 7 comments

Comments

@dmitshur
Copy link
Member

dmitshur commented Feb 9, 2017 •
edited
Loading

I've mentioned this in #552 (comment), but I've confirmed it happens in 1.8 only now.

I've investigated it and found the root cause.

image

It happens with GopherJS 1.8-wip only when "os" package is imported (not necessarily directly). That package is often imported by other packages, such as "net/http", or if you're getting os.Stdout, etc.

It happens because of Executable() addition to os package in Go 1.8.

As a result, os.Getwd() gets called as part of os package initialization:

var initCwd, initCwdErr = Getwd()

Source: https://github.com/golang/go/blob/09762ccff79ebf08839f8954ab99c17d41f071e2/src/os/executable_darwin.go#L9.

Calling os.Getwd() in browser ends up making a call to Syscall, which causes the warning to get printed to console (note that it's actually printed as an error to console).
@dmitshur
Copy link
Member Author

dmitshur commented Feb 10, 2017 •
edited
Loading

There are multiple ways we can resolve this. Do you have preferences on this @neelance?

We could override Getwd on browser to return error right away, without making syscalls.

We could try to override initCwd and initCwdErr variables Getwd() never gets called, but I'm not sure if it's possible since it's single declaration for 2 variables, and the variable names are unexported, so they might change between Go versions more often... They might also have different names depending on the desktop architecture (note that the linked file is executable_darwin.go, for darwin; but there are others).

@dmitshur
Copy link
Member Author

There are multiple ways we can resolve this. Do you have preferences on this @neelance?

Friendly ping @neelance.

@neelance
Copy link
Member

What about excluding executable_darwin.go from the build?

@neelance
Copy link
Member

Btw: Thanks for pinging.

@dmitshur
Copy link
Member Author

What about excluding executable_darwin.go from the build?

note that the linked file is executable_darwin.go, for darwin; but there are others

image

There are multiple files, we'd have to exclude them all. For example, if someone uses GopherJS on Windows, their default GOOS value will be windows, and the file executable_windows.go will be used instead.

@dmitshur
Copy link
Member Author

dmitshur commented Feb 16, 2017 •
edited
Loading

Although, it's worth noting executable_windows.go doesn't try to call os.Getwd. But it does import "internal/syscall/windows", which I expect would still be a bad idea in GopherJS.

dmitshur added a commit that referenced this issue Feb 16, 2017
@dmitshur
build, compiler/natives/src/os: Remove syscalling os.Executable imple…
65da89e 
…mentation.

Replace it with a not-implemented-erroring one.

This fixes the issue #583 where on darwin a call to os.Getwd is made,
which makes syscalls, and causes a warning to be printed to console:

	warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md

os.Executable is documented to be unsupported on nacl:

	// Executable is not supported on nacl or OpenBSD (unless procfs is
	// mounted.)

GOARCH=js is similar to nacl in many ways, so it's pretty expected
os.Executable wouldn't be supported here either.

Use https://github.com/golang/go/blob/990124da2a6ca5a54b38733b51018e2f8758cfae/src/os/executable_procfs.go#L21
as template for error message.

Fixes #583.
@dmitshur
Copy link
Member Author

This go1.8-branch-specific issue has been resolved in 65da89e, which is now a part of go1.8 branch. Closing.

dmitshur added a commit that referenced this issue Feb 16, 2017
@dmitshur
build, compiler/natives/src/os: Remove syscalling os.Executable imple…
7522980 
…mentation.

Replace it with a not-implemented-erroring one.

This fixes the issue #583 where on darwin a call to os.Getwd is made,
which makes syscalls, and causes a warning to be printed to console:

	warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md

os.Executable is documented to be unsupported on nacl:

	// Executable is not supported on nacl or OpenBSD (unless procfs is
	// mounted.)

GOARCH=js is similar to nacl in many ways, so it's pretty expected
os.Executable wouldn't be supported here either.

Use https://github.com/golang/go/blob/990124da2a6ca5a54b38733b51018e2f8758cfae/src/os/executable_procfs.go#L21
as template for error message.

Fixes #583.
dmitshur added a commit that referenced this issue Feb 16, 2017
@dmitshur
build, compiler/natives/src/os: Remove syscalling os.Executable imple…
b36bf38 
…mentation.

Replace it with a not-implemented-erroring one.

This fixes the issue #583 where on darwin a call to os.Getwd is made,
which makes syscalls, and causes a warning to be printed to console:

	warning: system calls not available, see https://github.com/gopherjs/gopherjs/blob/master/doc/syscalls.md

os.Executable is documented to be unsupported on nacl:

	// Executable is not supported on nacl or OpenBSD (unless procfs is
	// mounted.)

GOARCH=js is similar to nacl in many ways, so it's pretty expected
os.Executable wouldn't be supported here either.

Use https://github.com/golang/go/blob/990124da2a6ca5a54b38733b51018e2f8758cfae/src/os/executable_procfs.go#L21
as template for error message.

Fixes #583.
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
2 participants
@neelance @dmitshur