I agree on the fact it is suspicious that libglapi,dll was asked for
considering glapi is built as a static library part of opengl32.dll by default.
If I understood correctly what gles variable does, it turns glapi into a shared
library and that's all there is to it and probably as a side
I still can't make much sense of that github issue thread.
Applications on Windows use opengl32.dll for acceleration, not
libEGL/libGLESv1/libGLESv2 as these are not provided by the OS. The
only place you see these DLLs are things like GLES -> D3D11/GL
translators like Angle.
So the
Well, all this started in that Github issue thread. That guy @elkhalafy was
using llvmpipe to get Blender 2.80 to work on his system with unsupported (too
old) iGPU. I don't know what he did but it resulted in Blender failing with
missing libglapi.dll. So I researched about how to build it and
I don't know what gles=y entails anymore, but if it's broken we should
simply remove it.
That said, our WGL GLES contexts, via WGL_EXT_create_context_es2_profile
extension, even without gles=y option.
So what exactly are you looking for here?
Jose
On 18/10/18 13:02, Liviu Prodea wrote:
scons build=release platform=windows machine=x86 gles=y libgl-gdi osmesa
Creating library build\windows-x86\mesa\drivers\osmesa\osmesa.lib and object
build\windows-x86\mesa\drivers\osmesa\osmesa.exp
osmesa.obj : error LNK2001: unresolved external symbol
__imp___glapi_check_multithread
osmesa.obj
