On 2020-06-29 22:09, Martin Storsjö wrote:
On Tue, 30 Jun 2020, Biswapriyo Nath wrote:
opengl32.dll and glu32.dll are present latest Windows Insider build for
ARM64 in System32 folder.
What does wglinfo-aarch64.exe say when you run on that version then?
Does it actually provide an interface to the real hardware
implementation? (Now when I come to think of it, I remember seeing a
mention of something like that in May.)
Maybe they are using Angle ? https://github.com/Microsoft/angle
Providing it unconditionally in mingw-w64 is a bit problematic, because
there's quite a bit of build systems (in particular, within VLC) that do
try compiling things with OpenGL, and if available, they use it.
That means, if we add that import library, the VLC built with current
mingw-w64 wouldn't run on current, existing Windows on ARM64.
We already use Angle in Qt on Windows so there's a chance it would work.
But that's probably not good enough for most projects.
To work around that, all the relevant build systems would need to add
explicit checks like "if (windows && arm) disable opengl;" instead of
just relying on configure time detection, and such custom checks aren't
really popular.
I think that's a more general problem than just OpenGL. Now that there
is one Windows 10 with multiple variants it becomes trickier to target
the whole Win10 base and use features when they are available. MS solves
that by providing a SDK for the minimum OS target you want to support
and link with DLLs that have all entries available at that version and
above.
Mingw doesn't have this system. It may be solved in parts in header by
hiding API depending on the NTDDI_VERSION. That would work for detection
that relies on headers, not the ones that test linking without checking
headers first.
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
