Please answer these questions before submitting your issue. Thanks!
go version)?go1.9 darwin/amd64
probably
go env)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tschinke/go"
GORACE=""
GOROOT="/Users/tschinke/repos/cewe_myphotos-android/goroot"
GOTOOLDIR="/Users/tschinke/repos/cewe_myphotos-android/goroot/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/bv/6rt5ck194ls704dz9p4c0hlh0000gn/T/go-build942922073=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
Using goMobile with latest Android NDK r16 is not compatible with current goMobile and causes a build failure.
A successful gomobile build
Example:
gomobile bind -target=android -o mylib.aar my/export/package
xxx/backend-go/deps/bin/gomobile: go build -pkgdir=xxx/backend-go/deps/pkg/gomobile/pkg_android_arm64 -buildmode=c-shared -o=/tmp/gomobile-work-179627284/android/src/main/jniLibs/arm64-v8a/libgojni.so /tmp/gomobile-work-179627284/androidlib/main.go failed: exit status 2
seq_android.c:213:3: error: implicitly declaring library function 'memcpy' with type 'void *(void *, const void *, unsigned long)' [-Werror,-Wimplicit-function-declaration]
seq_android.c:213:3: note: include the header
goMobile still works with NDK r15c, so I could imagine that this is caused by "The deprecated headers have been removed. Unified Headers are now simply The Headers."
Changelog for r16:
https://android.googlesource.com/platform/ndk/+/ndk-release-r16/CHANGELOG.md
Migration note for unified headers:
https://android.googlesource.com/platform/ndk/+/ndk-release-r16/docs/UnifiedHeadersMigration.md
I experienced (what I think is) the same bug as you describe.
Here's how I workarounded it:
I edited the seq_android.c.support file and added this line: #include <string.h>
On my setup, the file is here: ~/golang/workspace/src/golang.org/x/mobile/bind/java/seq_android.c.support
I would create a PR, but "Unfortunately, the Go project doesn't use GitHub's Pull Requests" (from here), and the contribution guide is too long for a one line casual contribution, so in case this helps someone, here's the diff:
diff --git a/bind/java/seq_android.c.support b/bind/java/seq_android.c.support
index fbc6d55..7c0f483 100644
--- a/bind/java/seq_android.c.support
+++ b/bind/java/seq_android.c.support
@@ -11,6 +11,7 @@
#include <jni.h>
#include <stdint.h>
#include <stdio.h>
+#include <string.h>
#include <unistd.h>
#include <pthread.h>
#include "seq.h"
Change https://golang.org/cl/79499 mentions this issue: x/mobile: Build on NDK r16
What's going on this? I'd be really happy if the change could be committed soon.
OK so I had the same issue, and editing seq_android.c.support fixed it for me.
I see this has been merged - when can I expect this to make it onto my machine through a new version of... something?
I've just started using gomobile and am finding nothing but roadblocks - is gradle 4.4/android sdk 27/com.android.tools.build:gradle:3.0.1 supposed to work?
The bind example from the guide https://github.com/golang/go/wiki/Mobile is a complete mess with a current version of Android studio or the above items.
I guess it does teach you a lot about go and building stuff, but it doesn't exactly leave a good impression - the reason I went in search of go was compiling my native C++ library with boost and all on 5 platforms (windows, linux, android, ios, osx) is an absolute nightmare...
Surely I'm doing something wrong and go isn't this flakey??
Most helpful comment
I experienced (what I think is) the same bug as you describe.
Here's how I workarounded it:
I edited the
seq_android.c.supportfile and added this line:#include <string.h>On my setup, the file is here:
~/golang/workspace/src/golang.org/x/mobile/bind/java/seq_android.c.supportI would create a PR, but "Unfortunately, the Go project doesn't use GitHub's Pull Requests" (from here), and the contribution guide is too long for a one line casual contribution, so in case this helps someone, here's the diff: