qt5base-lts/mkspecs/common/windows-gles.conf

# Output name of Qt's ANGLE GLES library. (Note that this is different from upstream ANGLE)
LIBQTANGLE_NAME = QtANGLE

# Set up .lib files used for linking
QMAKE_LIBS_OPENGL_ES2 = -l$${LIBQTANGLE_NAME} $$QMAKE_LIBS_OPENGL_ES2
QMAKE_LIBS_OPENGL_ES2_DEBUG = -l$${LIBQTANGLE_NAME}d $$QMAKE_LIBS_OPENGL_ES2_DEBUG
Merge ANGLE's libEGL and libGLESv2 into QtANGLE This is needed in order to be able to specify a custom location of the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs by just having the absolute path to QtANGLE.dll as the argument to LoadLibrary(). Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard linked against libGLESv2. If we wanted to load libEGL from a custom location, we couldn't load libEGL by calling LoadLibrary with the absolute path to libEGL, because libEGL had problems finding libGLESv2. One solution to that could have been to call SetDllDirectory() with the path to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL directory would point to both ANGLE libs, this would ensure that the libGLESv2 was also found. Unfortunately, this approach is not thread safe (SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same process). Therefore, we chose to merge the two libraries into one to circumvent the whole problem. At the same time, this patch also enables loading of two different ANGLE libraries into the same process at once without renaming them: This was not possible before because libEGL hard linked to libGLESv2.dll. When libGLESv2.dll was already loaded, the second instance of libEGL would simply link against the already loaded version of libGLESv2.dll. This behavior is documented in the LoadLibraryEx documentation on MSDN: "If the string specifies a module name without a path and more than one loaded module has the same base name and extension, the function returns a handle to the module that was loaded first." Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com> 2016-10-25 14:56:02 +00:00			`# Output name of Qt's ANGLE GLES library. (Note that this is different from upstream ANGLE)`
			`LIBQTANGLE_NAME = QtANGLE`

			`# Set up .lib files used for linking`
			`QMAKE_LIBS_OPENGL_ES2 = -l$${LIBQTANGLE_NAME} $$QMAKE_LIBS_OPENGL_ES2`
Fix linking against ANGLE in debug builds Copy and paste bug introduced by 780105f9062dec350bbe2a6800c40db3e6382578 Change-Id: I64309f1ea6857926b19afd038094adf1cffa6c17 Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> 2016-11-01 07:37:57 +00:00			`QMAKE_LIBS_OPENGL_ES2_DEBUG = -l$${LIBQTANGLE_NAME}d $$QMAKE_LIBS_OPENGL_ES2_DEBUG`
Merge ANGLE's libEGL and libGLESv2 into QtANGLE This is needed in order to be able to specify a custom location of the ANGLE libs, and enables us to perform a LoadLibrary of ANGLE libs by just having the absolute path to QtANGLE.dll as the argument to LoadLibrary(). Previously, we had two ANGLE libraries: libEGL and libGLESv2. libEGL hard linked against libGLESv2. If we wanted to load libEGL from a custom location, we couldn't load libEGL by calling LoadLibrary with the absolute path to libEGL, because libEGL had problems finding libGLESv2. One solution to that could have been to call SetDllDirectory() with the path to the ANGLE libs before calling LoadLibrary("libEGL.dll"). Since the DLL directory would point to both ANGLE libs, this would ensure that the libGLESv2 was also found. Unfortunately, this approach is not thread safe (SetDllDirectory will affect all subsequent LoadLibrary(Ex) from the same process). Therefore, we chose to merge the two libraries into one to circumvent the whole problem. At the same time, this patch also enables loading of two different ANGLE libraries into the same process at once without renaming them: This was not possible before because libEGL hard linked to libGLESv2.dll. When libGLESv2.dll was already loaded, the second instance of libEGL would simply link against the already loaded version of libGLESv2.dll. This behavior is documented in the LoadLibraryEx documentation on MSDN: "If the string specifies a module name without a path and more than one loaded module has the same base name and extension, the function returns a handle to the module that was loaded first." Change-Id: Ic1d886ba802be72ddcf01235bafaedcef662762e Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@qt.io> Reviewed-by: Oliver Wolff <oliver.wolff@qt.io> Reviewed-by: Friedemann Kleint <Friedemann.Kleint@qt.io> Reviewed-by: Jan Arve Sæther <jan-arve.saether@theqtcompany.com> 2016-10-25 14:56:02 +00:00