Skip to content

"undeclared name: efaceOf" build error when using different GOPATHs #462

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
fabian-z opened this issue May 13, 2016 · 6 comments
Closed

"undeclared name: efaceOf" build error when using different GOPATHs #462

fabian-z opened this issue May 13, 2016 · 6 comments
Labels
enhancement

Comments

@fabian-z
Copy link

fabian-z commented May 13, 2016 •
edited
Loading

This reproduction case evolved from issue #434. Related issue #459.

Go version go1.6.2 linux/amd64
GopherJS master ce68d34

$ pwd
/tmp
$ mkdir go go2
$ export GOPATH=/tmp/go
$ go get github.com/gopherjs/gopherjs
$ export PATH=/tmp/go/bin:$PATH
$ cd go2
$ mkdir -p src/testpackage/
$ cat src/testpackage/main.go 
package main

func main() {

println("Hello, world!")

}

$ export GOPATH=/tmp/go2
$ go build testpackage
$ ./testpackage 
Hello, world!
$ gopherjs build testpackage
../../usr/lib/go/src/runtime/error.go:58:7: undeclared name: efaceOf
@dmitshur
Copy link
Member

Thanks for putting this together, it will help resolve the issue.

@iansmith
Copy link

I had this same problem. The gopherjs source code (for example the gopherjs implementation of the runtime package) has to be in the GOPATH.

@fabian-z
Copy link
Author

fabian-z commented May 14, 2016 •
edited
Loading

If this is indeed the root cause of this issue (and judging from my experience documented in #434 this may very well be the case), I would suggest that the gopherjs command should also look into /vendor of the package being build for its own source code. That would at least resolve the common case of a package which vendors all of its dependencies.
Maybe offering an option to install the needed source into GOROOT somehow would be a possible approach to cover the remaining cases. I guess the error message should improve, too.

@neelance neelance mentioned this issue May 14, 2016
Closed
@pwaller
Copy link

pwaller commented Feb 26, 2017

I just hit this error and couldn't figure out why. What fixed it for me was to ensure gopherjs was uptodate and the run go install -v github.com/gopherjs/gopherjs

dmitshur added a commit that referenced this issue Apr 7, 2018
@dmitshur
build: Load js, nosync packages from gopherjspkg rather than GOPATH.
aebb4ea 
The Go stdlib overrides (i.e., compiler/natives package) are already
embedded into the GopherJS build system. This makes it possible for the
gopherjs binary to access them even if the gopherjs repository is not
present in GOPATH (e.g., because it was deleted, or because it's
vendored).

Doing that for natives but not the js, nosync packages makes little
sense, since the gopherjs repository still needs to exist in GOPATH.

This change fixes that. By embedding the core GopherJS packages
analogously to natives, the gopherjs binary becomes more standalone.
Now, it only requires GOROOT/src to contain the matching version of Go
source code.

Non-core GopherJS packages are not embedded (e.g., the GopherJS
compiler itself). That means it needs to exist in GOPATH to be
buildable (otherwise, the user gets a "cannot find package" error).
This is expected just like with any other normal Go package.

Fixes #462.
Helps #415.
@dmitshur
Copy link
Member

dmitshur commented Apr 7, 2018

Thanks again for the reproduce steps.

I followed them today, and the result is different. I suspect it's because of the change to embed natives into the GopherJS build system via a virtual filesystem (commit ab917e0).

However, the github.com/gopherjs/gopherjs/js package isn't embedded. So the current error is:

$ gopherjs build testpackage
cannot find package "github.com/gopherjs/gopherjs/js" in any of:
	/usr/local/go/src/vendor/github.com/gopherjs/gopherjs/js (vendor tree)
	/usr/local/go/src/github.com/gopherjs/gopherjs/js (from $GOROOT)
	/tmp/go3/src/github.com/gopherjs/gopherjs/js (from $GOPATH)

I have a fix that will resolve this issue completely. It will do so by embedding the js and nosync core GopherJS packages (they're needed to build the Go standard library with GopherJS compiler) into the GopherJS build system. It will be just like the natives that are already embedded.

dmitshur added a commit that referenced this issue Apr 8, 2018
@dmitshur
build: Load js, nosync packages from gopherjspkg rather than GOPATH.
e3253c7 
The Go stdlib overrides (i.e., compiler/natives package) are already
embedded into the GopherJS build system. This makes it possible for the
gopherjs binary to access them even if the gopherjs repository is not
present in GOPATH (e.g., because it was deleted, or because it's
vendored).

Doing that for natives but not the js, nosync packages makes little
sense, since the gopherjs repository still needs to exist in GOPATH.

This change fixes that. By embedding the core GopherJS packages
analogously to natives, the gopherjs binary becomes more standalone.
Now, it only requires GOROOT/src to contain the matching version of Go
source code.

Non-core GopherJS packages are not embedded (e.g., the GopherJS
compiler itself). That means it needs to exist in GOPATH to be
buildable (otherwise, the user gets a "cannot find package" error).
This is expected just like with any other normal Go package.

Fixes #462.
Helps #415.
dmitshur added a commit that referenced this issue Apr 8, 2018
@dmitshur
build: Load js, nosync packages from gopherjspkg rather than GOPATH.
03ee835 
The Go stdlib overrides (i.e., compiler/natives package) are already
embedded into the GopherJS build system. This makes it possible for the
gopherjs binary to access them even if the gopherjs repository is not
present in GOPATH (e.g., because it was deleted, or because it's
vendored).

Doing that for natives but not the js, nosync packages makes little
sense, since the gopherjs repository still needs to exist in GOPATH.

This change fixes that. By embedding the core GopherJS packages
analogously to natives, the gopherjs binary becomes more standalone.
Now, it only requires GOROOT/src to contain the matching version of Go
source code.

Non-core GopherJS packages are not embedded (e.g., the GopherJS
compiler itself). That means it needs to exist in GOPATH to be
buildable (otherwise, the user gets a "cannot find package" error).
This is expected just like with any other normal Go package.

Fixes #462.
Helps #415.
@dmitshur dmitshur mentioned this issue Apr 8, 2018
Merged
@dmitshur
Copy link
Member

dmitshur commented Apr 8, 2018

I've created PR #787 that'll resolve this issue.

dmitshur added a commit that referenced this issue Apr 10, 2018
@dmitshur
build: Load js, nosync packages from gopherjspkg rather than GOPATH.
b97b481 
The Go stdlib overrides (i.e., compiler/natives package) are already
embedded into the GopherJS build system. This makes it possible for the
gopherjs binary to access them even if the gopherjs repository is not
present in GOPATH (e.g., because it was deleted, or because it's
vendored).

Doing that for natives but not the js, nosync packages makes little
sense, since the gopherjs repository still needs to exist in GOPATH.

This change fixes that. By embedding the core GopherJS packages
analogously to natives, the gopherjs binary becomes more standalone.
Now, it only requires GOROOT/src to contain the matching version of Go
source code.

Non-core GopherJS packages are not embedded (e.g., the GopherJS
compiler itself). That means it needs to exist in GOPATH to be
buildable (otherwise, the user gets a "cannot find package" error).
This is expected just like with any other normal Go package.

Fixes #462.
Helps #415.
dmitshur added a commit that referenced this issue Apr 20, 2018
@dmitshur
build: Load js, nosync packages from gopherjspkg rather than GOPATH.
c121b3d 
The Go stdlib overrides (i.e., compiler/natives package) are already
embedded into the GopherJS build system. This makes it possible for the
gopherjs binary to access them even if the gopherjs repository is not
present in GOPATH (e.g., because it was deleted, or because it's
vendored).

Doing that for natives but not the js, nosync packages makes little
sense, since the gopherjs repository still needs to exist in GOPATH.

This change fixes that. By embedding the core GopherJS packages
analogously to natives, the gopherjs binary becomes more standalone.
Now, it only requires GOROOT/src to contain the matching version of Go
source code.

Non-core GopherJS packages are not embedded (e.g., the GopherJS
compiler itself). That means it needs to exist in GOPATH to be
buildable (otherwise, the user gets a "cannot find package" error).
This is expected just like with any other normal Go package.

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

No branches or pull requests
4 participants
@iansmith @pwaller @dmitshur @fabian-z