the procedure entry point __gxx_personality_v0 could not be located

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.

Answers


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


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


Need Your Help

Do DOM tree elements with ids become global variables?

javascript dom global-variables getelementbyid identifier

Working on an idea for a simple HTMLElement wrapper I stumbled upon the following for Internet&nbsp;Explorer and Chrome:

Good way to procedurally generate a "blob" graphic in 2D

language-agnostic graphics noise procedural-generation

I'm looking to create a "blob" in a computationally fast manner. A blob here is defined as a collection of pixels that could be any shape, but all connected. Examples: