IT WERKS!!!
Thank you so much @mmozeiko , for me this is a great achievement! Been pulling my hair out all week!!
What you said was 100% spot-on, glfw was expecting ´libEGL.so.1´ and ´libGLESv2.so.2´ as dictated by ´egl_context.c´.
The built ANGLE libraries are named ´libEGL.so´ and ´libGLESv2.so´, so they were found at their specified paths by the linker, hence no errors during compilation BUT glfw couldn’t load them from that path so it looked in ´/usr/lib´ where all my other libraries are and loaded the native ones instead, but now function addresses couldn’t line up so the program didn’t work!
The solution is to go to the ´angle/out/Release/´ dir where the built libraries end up and simply create the symlinks yourself:
ln -s libEGL.so libEGL.so.1
ln -s libGLESv2.so libGLESv2.so.2
Then, during compilation, it will find and link against the files without the .1 and .2 suffix but when the program tries to load the libraries during execution, the symlinks redirect it to the real files.
Now glGetString FINALLY returns these instead of NULL:
Renderer: ANGLE (Intel, Mesa Intel(R) HD Graphics 5500 (BDW GT2), OpenGL 4.6 (Core Profile) Mesa 23.0.4)
OpenGL version supported OpenGL ES 3.0.0 (ANGLE 2.1.21545 git hash: f2e0f8a0b236)
OpenGL vendor: Google Inc. (Intel)
I had to remove glad again as that was causing a runtime error after glfw initialization despite not being actually used / called:
[65544] EGL: Failed to create window surface: A NativeWindowType argument does not refer to a valid native window
Your clever trick of manually retrieving the gl function addresses from glfw to determine the actually-loaded gl library can be very telling and I’ll save that one to disk in the hope I’ll never need that one again.
But now it’s not necessary to do that anymore, the gl functions “just work”, probably thanks to glfw but it’s beyond me how that sorcery works.
So again, thank you very much for your help!
