Closed computermouth closed 1 year ago
Does adding -Wl,--enable-stdcall-fixup
when linking, fixes your issue?
SDL seems to require linking against specifically the 32bit mingw library.
Where does this condition come from?
When the symbol is followed by @N
it means that the __stdcall
calling convention is used (N is the total size in bytes of the arguments). __imp
is prepended when a function is declared __declspec(dllexport)
. Also, for __cdecl functions on x86 an underscore is prepended to the symbol name
However on x64 and ARM64 there's just one calling convention, so doesn't matter much.
See:
The calling convection of Khronos API is specified in ${MINGW_PREFIX}/include/KHR/khrplatform.h
: https://github.com/KhronosGroup/EGL-Registry/blob/main/api/KHR/khrplatform.h (included by GLES2 headers).
Here's a relevant excerpt:
/*-------------------------------------------------------------------------
* Definition of KHRONOS_APIENTRY
*-------------------------------------------------------------------------
* This follows the return type of the function and precedes the function
* name in the function prototype.
*/
#if defined(_WIN32) && !defined(_WIN32_WCE) && !defined(KHRONOS_STATIC)
/* Win32 but not WinCE */
# define KHRONOS_APIENTRY __stdcall
#else
# define KHRONOS_APIENTRY
#endif
So on x86 the __stdcall
calling convention should be used. Looks like angleproject exports __cdecl
functions instead
Does adding -Wl,--enable-stdcall-fixup when linking, fixes your issue?
It did not, issue persists
SDL seems to require linking against specifically the 32bit mingw library.
Where does this condition come from?
In all environments, sdl2-config --libs
and pkg-config --libs sdl2
return -lmingw32
So on x86 the stdcall calling convention should be used. Looks like angleproject exports cdecl functions instead
So I should maybe look to see if that's a setting in the angle build scripts? Is one of these the preferred choice of MSYS2?
In all environments,
sdl2-config --libs
andpkg-config --libs sdl2
return-lmingw32
That -lmingw32
does not mean the program has to be compiled in 32-bit mingw environment. libmingw32.a
is a static library required for C runtime functions. It is present in all supported CPU architectures.
Uh, actually ANGLE uses a .def file, so shouldn't export decorated names: https://github.com/google/angle/blob/main/src/libGLESv2/libGLESv2_autogen.def
libmingw32.a is a static library required for C runtime functions. It is present in all supported CPU architectures.
I don't want to get to side-tracked on the real issue, but where do I get it from? In my mingw64 env, there's no such lib
$ ls /mingw32/lib/libmingw32.a
/mingw32/lib/libmingw32.a
$ ls /mingw64/lib/libmingw32.a
ls: cannot access '/mingw64/lib/libmingw32.a': No such file or directory
but where do I get it from? In my mingw64 env, there's no such lib
Just download the compiler toolchain in mingw64 or other environment as you did in mingw32. Buy gcc or clang, get crt free :)
Uh, actually ANGLE uses a .def file, so shouldn't export decorated names: https://github.com/google/angle/blob/main/src/libGLESv2/libGLESv2_autogen.def
Oh, right, I forgot I already saw that the exported names are normal. So the problem starts in the Khronos headers
Just download the compiler toolchain in mingw64 or other environment as you did in mingw32. Buy gcc or clang, get crt free :)
Well now I just feel silly, thanks!
Well, actually I think that the issue is in angleproject π
It turns out it works in mingw64. Weird. Given the following:
#if defined(_WIN32) && !defined(_WIN32_WCE) && !defined(KHRONOS_STATIC)
/* Win32 but not WinCE */
# define KHRONOS_APIENTRY __stdcall
#else
# define KHRONOS_APIENTRY
#endif
I suppose that makes sense, as we're probably _WIN64 or something
It also works with mingw32 if I modify the the KHR/khrplatform.h
# define KHRONOS_APIENTRY __stdcall
to
# define KHRONOS_APIENTRY
However, if I run dumpbin /EXPORTS D:\msys64\mingw32\bin\libGLESv2.dll
the symbols look right:
Could you share a basic SDL2/GLES program to test with?
However, if I run
dumpbin /EXPORTS D:\msys64\mingw32\bin\libGLESv2.dll
the symbols look right:
Oh wow, that's extra weird.
Here's what I've been using: https://gist.github.com/computermouth/3ccf270148e7e7b1dc7f511c8230212f
I should note that while this sample works fine on linux with actual GLES2, I have yet to get it to truly work with ANGLE. The closest I've gotten on two linux distros and windows is a black screen.
If those symbols are really exported with __stdcall
calling convention, but the library is linked with that .def
file, that might be the reason for the issue here.
It would probably need to use a .def
file with the correctly mangled names on 32-bit platforms.
See also, e.g., the patch that is applied for the vulkan-loader package:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-vulkan-loader
I should note that while this sample works fine on linux with actual GLES2, I have yet to get it to truly work with ANGLE. The closest I've gotten on two linux distros and windows is a black screen.
For the record, the problem here was that I wasn't setting the OPENGL_ES_DRIVER hint: https://github.com/msys2/MINGW-packages/issues/16971#issuecomment-1526043613. After adding that, it draws just fine.
Additionally, I've opened a thread in the ANGLE google group: https://groups.google.com/g/angleproject/c/gOdOOMTce_w
If I get no traction there, I'll start working on a .def
patch
Upstream does not support mingw toolchain. Asking support for that would be off-topic there, I guess.
Also, are you using 32 bit machine or OS which require that patch?
Weeeeeeell, no, not necessarily. I'm writing a game, which I intend to turn into an engine, so the more platforms the better. 32-bit Windows doesn't seem long for this world, so it's not really a big deal, and it seems armhf and i686 linux won't be affected by this, so that's really all my concerns. I suppose I could just do 64-bit only for Windows.
Strangely enough, it works on clang32 π€·ββοΈ
Tested with https://gist.github.com/vittorioromeo/5c5ad838fe5fe1bf54f9. Looking at the import libs (lib\libGLESv2.dll.a) I see:
mingw32:
_glWaitSync
__imp__glWaitSync
clang32:
_glWaitSync@16
Actually there are some @N functions in mingw32
's libGLESv2.dll.a, but all have prefixes like GL or EGL:
mingw32:
_GL_WaitSync@16
_EGL_WaitSync@12
To draw a parallel, I have also inspected libuser32.a
.
user32.dll
exports __stdcall
functions, and names are not decorated (so to easily use GetProcAddress). This is like angleproject's libGLESv2. However, mingw32\lib\libuser32.a
has @N
function names everywhere:
mingw32\lib\libuser32.a:
...
_TranslateAcceleratorW@12
_TrackPopupMenuEx@24
...
Strangely enough, it works on clang32 π€·ββοΈ
That's interesting. I suppose that might make sense as someone mentioned that mingw wasn't an upstream supported toolchain
Hmm, still doesn't work correctly.
#include <stdio.h>
#include <EGL/egl.h>
int main(void) {
printf("%p\n", &eglCreateWindowSurface);
return 0;
}
$ gcc c.c -lEGL
(.text+0x4b): undefined reference to `_imp__eglCreateWindowSurface@16'
Note that it hasn't reached the repo yet: https://packages.msys2.org/queue
Edit: it has now
Ok, thanks. It has been few days I assumed it is already there, but it was still in queue. It is working now.
Description / Steps to reproduce the issue
When attempting to link an sdl2/gles2 hello world against ANGLE's GLESv2, I get a bunch of undefined references.
Expected behavior
Proper linkage.
Actual behavior
As mentioned, failure to resolve ABI.
Other relevant information, ANGLE's libraries don't seem to export these symbols.
I'm not sure where the source of this
@4
is being introduced, but the number of underscores at the beginning of the function signature seems incorrect too. I've only tried on MINGW32, as SDL seems to require linking against specifically the 32bit mingw library.Verification
Windows Version
MINGW32_NT-10.0-22621
MINGW environments affected
Are you willing to submit a PR?
If I can determine the solution, absolutely