I have managed to (somehow) cross-compile Qt5 with the Mingw-w64 Project's compiler for 32-bit Windows. All of the libraries have been installed to ~/i686-w64-mingw32
.
I have a CMake-based Qt project that I am trying to cross-compile. By following these instructions, I have been able to get the project to compile. So far so good.
Unfortunately, when executing the resulting binary on Windows, I end up getting an error:
"The procedure entry point __gxx_personality_sj0 could not be located in the dynamic link library [application_name].exe"
* [application_name] is the full path to the main executable
I've heard that this type of problem can sometimes be caused by mixing libraries compiled with different versions of MinGW. But everything on this machine (all of the libraries and the executable) have all been compiled by the same compiler (the i686-w64-mingw32
toolchain).
Also, I find it odd that the error complains about the entry point being missing from the application executable instead of one of the .dll
files.
What could cause this error and what can be done to remedy it?
Finding the location of the wrong library:
- Open command prompt.
- Type "libstdc++-6.dll" and hit "Enter"
- A message box should appear with a path and a message: c:/somefolder/someapp/.../libstdc++-6.dll This file does not have a program associated with it... etc, etc.
The path is the answer.
- Running your app from within an IDE: %PATH% in IDE might be
different from the %PATH% in command prompt (see IDE settings). In
that case, putting "libstdc++-6.dll" into a batch file and running
the batch from within the IDE should show which particular instance
of the library your program is picking up.
My personal solution:
- Open "System Properties"->"Environment Variables" (in Windows 7, in my case) and make sure that both %PATH% variables (the one for your account AND system-wide variable %PATH%) begin with c:\mingw\bin (or whatever path you have for the library). Also, you may have to restart your IDE for it to pick up the new PATH.
In my experience, MS Windows' way of choosing the location within the %PATH% can be very erratic. Last time, I added one source file with a single function and included that function into my code. The program would always pick the wrong libstdc++-6.dll even when I deleted all the function's code and left only the 'return' statement. Every time that function was commented out (excluded), the program would run normally again. I suspect that sometimes Windows chooses PATH from "System Variables" and avoids "User variables" PATH (your Windows account's PATH) for some reason.
In the end, it turned out that the problem was caused by a wayward libstdc++-6.dll
somewhere in $PATH
. After ensuring that the copy built by Mingw-w64 was in the application's directory, everything worked.