The procedure entry point __gxx_personality_sj0 could not be located in…

Question

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

Answer 1

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.

Answer 2

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.