Build on macos M1 / Apple Silicon fails (GL/mobile-related)

[oubiwann]

I encountered this error when setting up a project for use in the tutorial:

go run ./cmd/tut/

# golang.org/x/mobile/gl
In file included from /Users/oubiwann/go/pkg/mod/golang.org/x/mobile@v0.0.0-20200329125638-4c31acba0007/gl/work.go:29:
./work.h:18:10: fatal error: 'OpenGLES/ES2/glext.h' file not found
#include <OpenGLES/ES2/glext.h>

I tried with:

• Go versions 1.16, 1.17
• engo version 1.0.4, 1.0.5, 1.0.6

After finding this bug, and the latest version of , I manually set this in go.mod:

    golang.org/x/mobile v0.0.0-20211109191125-d61a72f26a1a

and got past that error. I now see the following errors when using the latest x/mobile in all combinations of the versions listed above:

# github.com/EngoEngine/gl
/Users/oubiwann/go/pkg/mod/github.com/!engo!engine/gl@v1.0.12/gl_mobile.go:437:17: cannot refer to unexported name gl.line
/Users/oubiwann/go/pkg/mod/github.com/!engo!engine/gl@v1.0.12/gl_mobile.go:437:24: syntax error: unexpected newline, expecting comma or }
# golang.org/x/mobile/app
darwin_desktop.m:51:1: warning: method possibly missing a [super prepareOpenGL] call [-Wobjc-missing-super-calls]

Thoughts? Work-arounds?

[oubiwann]

Btw, hardly any of engo is being used in the above; I didn't get past the "hello world" ... this is the only file in the project so far:

package main

import (
    "github.com/EngoEngine/engo"
)

type myScene struct{}

// Type uniquely defines your game type
func (*myScene) Type() string {
    return "myGame"
}

// Preload is called before loading any assets from the disk,
// to allow you to register / queue them
func (*myScene) Preload() {}

// Setup is called before the main loop starts. It allows you
// to add entities and systems to your Scene.
func (*myScene) Setup(engo.Updater) {}

func main() {
    opts := engo.RunOptions{
        Title:  "Hello World",
        Width:  400,
        Height: 400,
    }
    engo.Run(opts, &myScene{})
}

[Noofbiz]

Hello! Thank you for bringing up this issue! I believe it is due to M1 Macs using the same build tags as iOS rather than MacOS, due to the way Apple is trying to merge the two into one build process (so iOS apps run on MacOS and vice-versa, and can all be done in Xcode). Unfortunately, I don't have an M1 Mac to test it out on, so there's not much I can do on my end until April/May when I'll be upgrading. If you'd like to play around with the build tags to get it working before then, I'd be more than happy to accept a pull request!