the procedure entry point __gxx_personality_v0 could not be located

雨燕双飞 提交于 2019-11-26 01:49:52

问题


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.


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




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




回答3:


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.




回答4:


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.



回答5:


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



来源:https://stackoverflow.com/questions/18668003/the-procedure-entry-point-gxx-personality-v0-could-not-be-located

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!