I'm developing an android game and have been primarily using a PC build (on windows) with the Mali OpenGL ES 2.0 emulator, with a secondary Android Studio build for the devices. For various reasons I'm trying to change over to Linux, and I have Linux Mint on a new PC, and so I'm trying to get a similar PC build working under linux, however I am an absolute beginner at linux.

It seems that a sensible option might be to use SDL on linux for stuff like creating a window, keyboard input etc. I gather that SDL2 is just the most up to date version of SDL, so I have been installing that with apt-get. However, when I try and install the Mali OpenGL ES emulator from ARM, I am getting a conflict:

installed package 'libegl1-mesa-dev' conflicts with the installed package 'libgles2-mesa-dev'

I am guessing this means that both SDL2 and Mali have some egl functionality, and they are treading on each others toes? There is some mention of this in the Mali help file:

Quote

Caution: OpenGL ES Emulator can conflict with other OpenGL ES implementations if such are
installed on your system. In particular, it will conflict with libEGL.so and libGLES.so libraries
installed with libgles2-mesa, libegl1-mesa packages. The dpkg tool will refuse to install
OpenGL ES Emulator DEB package. We recommend removing these conflicting Mesa libraries
prior to installing the Emulator. If for any reason you would like to have both conflicting software
installed on your machine, you can enforce the installation by adding --force-all command
line option:

Is this --force-all option what I should do? Or is there no way to get SDL2 and Mali to play together? If not SDL2 then how should I be using Mali under linux (i.e. what other API should I be talking to for creating a window, keyboard input etc?)?

The Mali OpenGL ES emulator works afaik by translating the openg es calls into regular desktop opengl calls, only allowing a subset of the full opengl, and performing lots of validation. This is what it appeared to do on windows, and everything I've read suggests it may be doing the same on linux.

What is slightly confusing is that there may be some kind of mesa opengl es support built into my linux, presumably as it may be running on hardware that *does* natively support opengl es(?). What that does if you call it without hardware support I have no idea, I wish I could find some decent linux for dummies tutorials lol.

I did manage to successfully install the mali emulator by first uninstalling sdl2. However, it gets worse. Their test cube app failed, apparently because it is trying to use the fallback compatibility opengl 3.0 profile instead of the core 4.3 profile on my kaby lake PC. The docs suggest this maybe because they've only tested it with nvidia hardware, but I haven't a clue, maybe I would have to force it to use the core profile somehow.

I'm now trying to get some PowerVR OpenGL ES emulator working, in the hope it plays nicer. I have managed to get some SDL / opengl es code to compile and link, but not show a triangle yet so I don't know if it is working...

Doh!  After all that, I'm getting the inkling that linux may just support opengl es 2.0 out of the box, via the open source mesa driver thingies. Here was me thinking it was something to do with the black mesa research facility. Anyway I've successfully got a triangle on the screen, am praying it is not software emulated...