the procedure entry point __gxx_personality_v0 could not be located

I had this problem as well. This fixed it for me:

1. Go to your MinGW folder (should be C:\MinGW)
2. Open the bin folder.
3. There should be a file called libstdc++-6.dll
4. Copy this into the same directory as your executable.

That should work...

The reason why this happens is because there can be a libstdc++-6.dll also in the WINDOWS\System32 directory (or in some other location where it can be found via PATH). Especially when you use different versions of MingW. So the solution is either to change the environment PATH variable in such a way that your MingW\bin directory is before the Windows system directory, replace the existing version with the newer one or copy the dll to the exectuable folder.

These errors are caused by mismatched DLLs.

For the messages in the question it is an incorrect version of libstdc++-6.dll , but you can see the message referring to other DLLs that were built with various versions of gcc for Windows; and even mentioning the .exe file being run.

The specific changes here are:

• basic_string|char_traits... - for C++11 there was a breaking ABI change to std::string
• __gxx_personality_v0 - I believe this has to do with which exception implementation is in use (gcc for Windows can use various of Dwarf2, Win32-SEH, SJLJ etc.)

You will see this message if an application compiled by one flavour of compiler links to a DLL compiled by a different flavour.

To see a list of found DLLs for an executable, you can open the executable in Dependency Walker and enable the "Full Paths" option. Another way is to use ldd if you have Cygwin or similar installed.

The most usual culprit is libstdc++-6.dll. Unfortunately the ABI change wasn't coupled with a change in version number of libstdc++; and it's not the default behaviour for the exception mode to appear in the filename. (You can change these things if building MinGW yourself).

I would recommend checking every DLL found by Dependency Walker and making sure it finds the ones from the same build of MinGW that you built your executable with. libgcc-s-*.dll is another one to look out for.

In fact I would recommend not having any of these DLLs on the system path. For development I load a PATH to the DLLs for the same compiler I'm compiling with; and for deployment I bundle the DLLs in the same directory as each executable, because the runtime DLL search always checks that directory first. Then there is no chance of finding an old DLL that happens to be on a system search path.

(Update 2019 These days I tend to use static linking, because deploying a larger file is less of a problem than getting stuck in DLL-hell).

See also:

• What is __gxx_personality_v0 for?
• Another suggestion to fix the problem is to use static linking so that your binary does not depend on these DLLs in the first place.

When I analyzed this in my case, I realized that there are 2 more versions of libstdc++-6.dll in system path configuration. One is in mingw64 and another is in postgres.

The problem is that they are not the same, their size is different too.

My solution is simple:
I move down the version of postgres below mingw64 version. And it works perfectly.