I can reproduce. It looks like a valid bug with /vendor/ support in a non-trivial case.

Possibly related commit and issue: f8510c9, #353
The test that was added in f8510c9 fails for me in master

My symptoms are a little bit different: I am getting weird errors from runtime during build, like
/usr/lib/go/src/runtime/error.go:58:7: undeclared name: efaceOf.
It is fixed by avoiding vendor code path as shown below.

My current workaround is to create a symbolic link in the vendor directory and run the gopherjs build with appropriate environment variable:

$ cd vendor
$ ln -s . src
$ cd ..
$ GOPATH=$(pwd)/vendor gopherjs build

Not pretty, but it gets the job done in the meantime (if you vendor all of your dependencies). I would be very glad to get rid of this workaround, though.

@fabian-z hah, thanks for the trick. That might help me in the meantime.

Unfortunately, I still get the error I described above (/usr/lib/go/src/runtime/error.go:58:7: undeclared name: efaceOf) with the current master d5d8eb5.

To give a little bit more detail: My application uses shurcooL/gopherjslib together with a forked out subtree of shurcooL/go: gopherjs_http - located at nfdesign/gopherjs_http.

In-process compilation of GopherJS works perfectly if given a populated GOPATH (see my former comment for the workaround). If the necessary packages are not contained in the GOPATH/src directory itself but only in GOPATH/src/package/vendor, the in-process build fails with the aforementioned error.

Currently, this means I have to use several workarounds and I'm actually not able to use my favorite IDE for debugging. I would appreciate any pointers for this issue.

I now had the chance to run a test with a gopherjs binary (instead of using gopherjslib) built from current master - the issue is the very same as described above (including the exact same error message).

#Failing invocation
$ /tmp/go/bin/gopherjs build app.js.go
../../../../../../../../usr/lib/go/src/runtime/error.go:58:7: undeclared name: efaceOf

#Workaround, no error and resulting JS works perfectly
$ cd vendor && ln -s . src && cd ..
$ GOPATH=vendor/ /tmp/go/bin/gopherjs build app.js.go 

So this issue is not related to my applications usage of gopherjslib / gopherjs_http in any way.

It is again fixed by providing a bogus GOPATH from the vendor directory (see workaround as described above).
Can a GopherJS dev clarify on whether I should open a new bug report, continue here or continue in #459? This clearly looks like a vendoring issue to me, so my proposal would be to reopen this issue since vendoring support is not completely fixed by f3c4379.

@fabian-z fwiw, I trusted them when they called it fixed and I did not retry with the exact repro I gave above. I can retry tomorrow if you want, however with the actual setup I use (which is pretty similar to the above example repro), the issue seems to be fixed for me, and I don't need the symlink trick you provided anymore.

@fabian-z oh wait, one additional bit of info that might matter: I did notice that I still had problems on go tip (which might look like the above error). Things only work with Go 1.6 for me (which is good enough for now).

@mpl Thanks for the information and your offer 😄 I just tried your repro case with my current Go version (1.6.2), where it works as it should for the gopherjs build command. I therefore think we are actually looking on two different issues here.
The connection of the undeclared name: efaceOf error to vendoring is still unclear to me - the fact that my workaround works at all suggests some relation though.

I was able to make a simple reproduction case out of my applications structure. I will use the same format as @mpl.

My revised reproduction case showed the issue is unrelated to vendoring. I will open a new issue for this case and link it here - sorry for the noise in this issue.