x/mobile: build of example _reverse_ failed #18210
Comments
|
/cc @crawshaw |
|
I am currently getting the same error. After some digging, I found that the gobind command cannot resolve the imports in the go files when GOOS is set to "android". This can be easily determined adding some output to the error handler function here: https://github.com/golang/mobile/blob/master/cmd/gobind/main.go#L110 Looking further, it seems that both the gobind and the gomobile command make use of the "go/importer" package, but gomobile creates a fake GOPATH so that the imports can be resolved, gobind however does not. https://github.com/golang/mobile/blob/master/cmd/gomobile/bind.go#L684 This is strange though, since it apparently works for others, so I'm stumped at this point. Does anyone have any ideas? |
|
I'm getting the same issue, with syncthing/syncthing-android#959 Btw #21319 is about the same issue, but claims that it was fixed with go 1.9 (which I am using). |
|
It works for me with |
|
Change https://golang.org/cl/101155 mentions this issue: |
The reverse bindings allow access to Java and ObjC APIs by importing Java/... and Objc/... package from Go. The gobind tool automatically create the bindings for the API referenced from the packages. The reverse example takes that ability too far, however. It creates a circular dependency from the Android databinding layout files to exported Go types while those same Go types access the Java classes generated by databinding. It works almost by accident, but not for newer Gradle versions. The circular dependencies are bad, but the underlying circular references created by using the reverse bindings this way are worse. I haven't found a satisfactory was to avoid retaining references to Go objects from Java and back without carefully and manually breaking cycles at appropriate times. One might succeed in ObjC where breaking reference cycles are already necessary, but not in Java. The reverse example is a nice technical feat, but promises more than it can deliver. Delete it. Fixes golang/go#19862 Fixes golang/go#18210 Change-Id: Ie6abd2a0ebd4c4ce36339d1294898e15f22f83bd Reviewed-on: https://go-review.googlesource.com/101155 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
The reverse bindings allow access to Java and ObjC APIs by importing Java/... and Objc/... package from Go. The gobind tool automatically create the bindings for the API referenced from the packages. The reverse example takes that ability too far, however. It creates a circular dependency from the Android databinding layout files to exported Go types while those same Go types access the Java classes generated by databinding. It works almost by accident, but not for newer Gradle versions. The circular dependencies are bad, but the underlying circular references created by using the reverse bindings this way are worse. I haven't found a satisfactory was to avoid retaining references to Go objects from Java and back without carefully and manually breaking cycles at appropriate times. One might succeed in ObjC where breaking reference cycles are already necessary, but not in Java. The reverse example is a nice technical feat, but promises more than it can deliver. Delete it. Fixes golang/go#19862 Fixes golang/go#18210 Change-Id: Ie6abd2a0ebd4c4ce36339d1294898e15f22f83bd Reviewed-on: https://go-review.googlesource.com/101155 Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version)?go version go1.7.3 linux/amd64
java -version
openjdk version "1.8.0_111"
OpenJDK Runtime Environment (build 1.8.0_111-8u111-b14-2ubuntu0.16.04.2-b14)
OpenJDK 64-Bit Server VM (build 25.111-b14, mixed mode)
What operating system and processor architecture are you using (
go env)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/nick/go"
GORACE=""
GOROOT="/home/nick/.local/share/umake/go/go-lang"
GOTOOLDIR="/home/nick/.local/share/umake/go/go-lang/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build237209226=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1
What did you do?
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
First of all, build of
golang.org/x/mobile/example/basicworks for me on both phone and PC.What did you expect to see?
Successful build
What did you see instead?
The text was updated successfully, but these errors were encountered: