the procedure entry point __gxx_personality_v0 could not be located

Question

Editor's Note: Error messages similar to "The procedure error point _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ could not be located in the dynamic link library libstdc++-6.dll" have the same cause and the same solutions apply.

---

I keep getting this error if I want to run my Irrlicht C++ Console Application in Windows:

the procedure entry point __gxx_personality_v0 could not be located in the dynamic link library libstdc++-6.dll

I am using CodeBlocks v12.11 with MinGW and the Irrlicht v1.8 engine. I set it up correctly. On my computer there is also a Qt installed with MinGW. Is it possible that there is a conflict?

This is the source code:

#include <irrlicht.h>

using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;

int main() {
    IrrlichtDevice *device = createDevice( video::EDT_OPENGL);

    if (!device)
        return 1;

    IVideoDriver* driver = device->getVideoDriver();
    ISceneManager* smgr = device->getSceneManager();
    IGUIEnvironment* guienv = device->getGUIEnvironment();

    guienv->addStaticText(L"Hello World", core::recti(10, 10, 100, 30));
    device->setWindowCaption(L"Hello World! - Irrlicht Engine Demo");

    while(device->run()) {
        driver->beginScene(true, true, SColor(250, 190, 1, 2));
        smgr->drawAll();
        guienv->drawAll();
        driver->endScene();
    }

    device->drop();
    return 0;
}

I configured the Compiler to C:\CodeBlocks\MinGW. Every file (there are some shown in the Settings) is located under bin, except make.exe. Is that normal?

The Auto-detect button also suggests the path above.

Valdovinos

Did you remember to edit the Settings->Search Directories under the linker tab? (so the linker can find the binaries.) – Disable

I've seen __gxx_personality_v0 errors when compiling with g++, then accidentally linking with gcc instead of g++ – Copaiba

Answer 1

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...

Camelot

great answer that saved me gazillion of energy – Spout

what i can do if i don't have libstdc++-6.dll in minGW folder? – Heathendom

Though it is a bit of a hobson's choice. Copy a 1M dll to the directory with your executable or live with a 500K executable after strip -s. (it actually adds to the overall size to copy the dll) – Lodestone

note that another option is to use static linking so that your binary does not depend on these DLLs anyway – Subset

If anyone found this solution to fix the problem then still be cautious, as the binary may also depend on other DLLs (such as libgcc_s, libwinpthread) with more subtle problems at runtime if the wrong version is used -- I would advise making sure all dependencies are checked, see my answer for detail – Subset

@Heathendom It should be there, are you in the \bin? – Proposal

Answer 2

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.

Ulcerous

I would recommend removing MinGW DLLs from system paths, and deploying the right version with each deployed executable. Uses more disk space yeah, but no chance of this sort of problem – Subset

A duplicate of libstdc++-6.dll can also be stored in the install directory of Git under mingw64\bin and/or mingw64\libexec\git-core. I simply deleted these files, and g++ and git still work – Epigenesis

Answer 3

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.

Subset

Answer 4

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.

Kashgar

Answer 5

copy libstdc++-6.dll found in mingw\bin to windows\system32 good luck

Procrastinate