Skip to content
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.

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

x/mobile/cmd/gomobile: init doesn't allow for android NDK platform selection #14618

tbogdala opened this issue Mar 3, 2016 · 6 comments


Copy link

@tbogdala tbogdala commented Mar 3, 2016

The Problem

I'm working on a prototype android google cardboard app that will need to use OpenGL ES 3.0/3.1 and most of the application is written in Go. I had a prototype up and running using OpenGL ES 2.0 but when I made the switch to ES 3.0 I found that I needed to write my own wrappers. I used the following block at the beginning of the wrapper to include the gl3.h header file:

#cgo LDFLAGS: -lGLESv3  -lEGL
#include <stdlib.h>
#include <GLES3/gl3.h>
#include <GLES3/gl3ext.h>
#include <GLES3/gl3platform.h>
import "C"

What happened was that I would get error messages when compiling in Android Studio with the gomobile bind portion of the process stating that it couldn't find the <GLES3/glh3.h> file.

When I investigated, it turns out that gomobile init for android arm always uses platform-15 from the NDK -- this platform version doesn't include the GLES3 headers because it doesn't support OpenGL ES 3.0 (requires platform 18+, per

The Hack

  1. I changed mobile/cmd/gomobile/env.go ndkConfig to point to platform-19.
  2. I changed mobile/cmd/gomobile/init.go useStrippedNDK to false so that it would download the full NDK as the stripped version doesn't have the platform minimum I needed.

With these changes a fresh gomobile init caused me to have the right platform headers in $GOPATH/pkg/gomobile/android-ndk-r10e/arm/sysroot/usr/include as well as the right libs in the parallel lib directory. From there I was able to compile the OpenGL ES 3.0 wrapper I was making and run the compiled app on my phone using specific gles3 shaders and functions.

What I Wanted To See

After I found the problem to be that gomobile init always uses the same platform, I think the best solution for me would be to have a flag for gomobile init to specify the platform level to support and another flag to control whether or not the full NDK is downloaded so that you don't have to modify the source code.

System Details

go version go1.6 windows/amd64
set GOARCH=amd64
set GOBIN=
set GOEXE=.exe
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOOS=windows
set GOPATH=C:/gocode
set GOROOT=C:\Go
set GOTOOLDIR=C:\Go\pkg\tool\windows_amd64
set CC=gcc
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0
set CXX=g++

Copy link

@tbogdala tbogdala commented Mar 3, 2016

I can try to contribute the changes if the idea of having more flags is acceptable.

Copy link

@hyangah hyangah commented Mar 3, 2016

/cc @crawshaw

@hyangah hyangah added this to the Unreleased milestone Mar 3, 2016
Copy link

@rakyll rakyll commented Mar 3, 2016

I don't think we should repack and redistribute all NDK versions for gomobile. Instead, users should be enabled to to target a specific standalone NDK toolchain by setting some env variables similar to CC and CXX.

Copy link

@gopherbot gopherbot commented Mar 15, 2016

CL mentions this issue.

Copy link

@eliasnaur eliasnaur commented Jan 17, 2017

Now that is in, fixing this should be much easier.

Copy link

@eliasnaur eliasnaur commented Mar 8, 2018

If goes in, you should be able to work around this problem by using gobind instead of gomobile and then building the JNI libraries manually. The CL includes a short example, and you can specify the platform version when you generate the standalone NDK toolchain.

@andybons andybons changed the title x/mobile/cmd/gomobile init doesn't allow for android NDK platform selection x/mobile/cmd/gomobile: init doesn't allow for android NDK platform selection May 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants