x/mobile: local import "." in non-local package

[iaburton]

What version of Go are you using (go version)?

$ go version
go version go1.11.4 linux/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ianb/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ianb/.gvm/pkgsets/go1.11.4/global"
GOPROXY=""
GORACE=""
GOROOT="/home/ianb/.gvm/gos/go1.11.4"
GOTMPDIR=""
GOTOOLDIR="/home/ianb/.gvm/gos/go1.11.4/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/mnt/SolidState/AndroidProjects/ContainerStation/app/src/cstation/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build725079142=/tmp/go-build -gno-record-gcc-switches"

What did you do?

GO111MODULE=off gomobile bind -target=android/arm64
after finding out about #27234

What did you expect to see?

Successful build

What did you see instead?

gomobile: go build -buildmode=c-shared -o=/tmp/gomobile-work-275087961/android/src/main/jniLibs/arm64-v8a/libgojni.so gobind failed: exit status 1
/tmp/gomobile-work-275087961/src/gobind/go_cstationmain.go:17:2: local import "." in non-local package

I recently updated from go1.10.x and vendoring to go1.11.4 to try modules. Unfortunately for me the first package/project I wanted to try them on was also one I planned on using gomobile with. After installing go1.11.4 and updating gomobile to the latest version, and working on my project for a bit, I attempted the first build, when I ran into the issue #27234. I'm not sure if the workaround mentioned in that thread works as I've yet to be able to build it successfully even once (a regular go build does fine of course). After running a GO111MODULES=off go get -v on each dependency to redownload into GOPATH, gomobile finally stopped compaining about being able to find things, and then started giving me the error I mention above, a local import in a non local package. I don't dot "." import anything in my code, but it looks like the error is from a file gomobile is generating.

I also tried the gomobile build again with modules on just to see what would happen since I also had the deps in GOPATH at that point, and got this:

gomobile: go build -buildmode=c-shared -o=/tmp/gomobile-work-661271854/android/src/main/jniLibs/arm64-v8a/libgojni.so gobind failed: exit status 1
go: finding github.com/iaburton/go-containerstation v0.0.0-20181127172758-7b47ccbbf5ce
go: finding golang.org/x/mobile v0.0.0-20181130133120-ca3c58166ed8
go: finding golang.org/x/text v0.3.0
go: finding golang.org/x/net v0.0.0-20181217023233-e147a9138326
can't load package: package gobind: unknown import path "gobind": cannot find module providing package gobind

For more context, I have a package https://github.com/iaburton/go-containerstation that I'm working on concurrently with another called 'cstation', the latter of which is the one that wraps the former to be used with gomobile. The former only uses the stdlib and the latter of course uses the former, as well as the x/net/http2 package. All of the exported types conform to the restrictions set by gomobile.

The project I'm attempting to build (which includes the cstation package) isn't on github yet but I should be able provide whatever information may be needed in order to figure this out. It's keeping me from working on this further. Thank you.

[iaburton]

Since the error was coming from a file generated by gobind, I reverted my gobind binary to one that was working on the earlier version of Go. While remaining under go1.11.4 with GO111MODULE=off I tried the build. Instead of an error gobind simply goes into a cpu/ram consuming spin, I let it eat 4gb until I killed it.

Next I reverted the gomobile binary as well, tried again, same thing. Then I kept the older gomobile binary but used the newer gobind binary, and I get the error in my original post. Removing GO111MODULE=off (in order to use modules) with the older binaries does the same thing, cpu/ram continue to grow until I kill it.

I'm not sure what's changed between the older binaries and the newer ones, but neither are working for me with go1.11.4 under any circumstance, go modules or otherwise. I'm still looking for a workaround.

[iaburton]

Alright well after losing most of the day to this, I have discovered what was wrong and a workaround.

I tested the above setup again with go1.10.7 and was getting the same problems, which didn't make sense to me since I had just used gomobile not long before with 1.10.5 and it was fine, then I realized something. In the past I've used gomobile to build/bind in my current directory, however at the time I've always been inside GOPATH (been using Go since 1.3). When I moved to go1.11.4 I also decided to create this new project outside of GOPATH. When I tested GO111MODULE=off my current directory was still outside of GOPATH even though I reinstalled all my dependencies in GOPATH and go build was working fine. When I read that gomobile doesn't work with modules yet in the other issue, I thought that meant my dependencies had to be in GOPATH as they always have been (leading to the situation in my previous post). I didn't think that meant my current working directory also had to be in GOPATH. I knew go mods allowed you to work outside of GOPATH, but I didn't make a connection that the working directory for gomobile would also be a problem since again, go build was fine outside of it, the original error in the other issue was about gomobile unable to find deps, and the error I was getting simply mentioned a local import in a non local package (not very helpful).

The workaround for now, along with continuing to use GO111MODULE=off, was to create a symlink from my GOPATH to my current working directory. Then it built fine. Hopefully this helps someone else, and maybe some documentation on this (if it is even needed after mod support is added) in the future would be appreciated.

[agnivade]

Sounds like you have resolved the issue. I think this entire confusion will go away once modules will be enabled by default (tentatively 1.13). If you feel the need for some specific documentation, please feel free to open a new issue.

Thanks.