Incompatable versions of libEGL and LIBGLESV2.

Using the 3.2 SDK, I am attempting to run a 32 bit PC emulated version of an application using VS2013. However, I am experiencing the error 'The application was unable to start correctly (0xc000007b).



Using ‘Dependency Walker’, it appears that that the versions of libEGL and libGLESV2 residing in ‘./Builds/Windows/x86_32’ are 64 bit. I am definitely using the correct paths/linkages.



Is there any way to obtain rebuilt 32 bit versions?

Hi,



I’ve tried to reproduce the issue locally, but the libraries in that location are 32-bit for me. It may be the case that there was a bug in our initial SDK installer that I wasn’t aware of. IIRC, we pushed out an updated installer binary after a few weeks due to known issues. Can you try running the latest 3.2 SDK installer to see if this fixes the problem?



It’s worth noting that the libraries in SDK_3.2/Builds/ are usually just shims to allow users to cross-compile. For Windows, we copy our emulation libraries to this location to save us maintaining a shim library for that OS. When you’re using the emulator to run applications, I’d recommend taking the libraries from PVRVFrame/Library/. Although they’re same, there’s a possibility that we could replace the SDK_3.2/Builds/ libraries with a shim in a future release.



Thanks,

Joe

Hi again…sorry for the delayed response, but I decided to revisit this issue (building a Win32 configuration)…



Tracing through the shell initialization, the first time the GL libraries are loaded is when eglCreateContext is called which links against the ‘.PVRVFrameLibraryWindows_x86_64’ regardless of any attempt to override via compiler options.



How can I redirect the linkage against the desired configuration libraries?



Edit Begin

In case its applicable…EGL_RENDERABLE_TYPE and EGL_OPENGL_ES2_BIT have been set when the config list is generated.

—*Edit End—

Hi,



From your description, it sounds like you’re linking against the x86-64 libraries when trying to build a x86-32 project. Can you try switching your project to 64-bit or point to the PVRVFrame 32-bit libraries when building to see if this resolves the issue?



Thanks,

Joe

Hi,



While reviewing posts on the forum, I noticed that this discussion is unresolved. Have you had any success with the emulator since we last spoke? Have you tried to use PVRVFrame from our most recent release (SDK 3.3) to see if it affects the issue?



Thanks,

Joe

Hi Joe,



The only way I could get my application to run was to copy the 32bit version of the libraries over to the windows_x86_32 folder (can’t remember where from). For some reason, the versions in the PVRFrame/Library/windows_x86_32 directory were also 64 bit.



This of course is only a temporary solution, as I needed to focus my attention elsewhere. When I upgrade to the latest version of your SDK, I’ll take another look, and make note here if I find anything unusual.



Thanks,

Jason

Hi Jason,



Thanks for the udpate. Sounds like a strange packaging issue. We did a cleanup of our installer builder for the 3.3 SDK release. Hopefully, the latest installer will behave better than the 3.2 SDK one.



Thanks,

Joe