C++ 无法找到过程入口点 __gxx_personality_v0

the procedure entry point __gxx_personality_v0 could not be located

提问by Niklas

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.

编者注：类似“程序错误点_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_无法在动态链接库中定位”的错误信息，libstdc++-6.dll原因相同，解决方法相同。

---

---

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

如果我想在 Windows 中运行我的 Irrlicht C++ 控制台应用程序，我会不断收到此错误：

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

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?

我将 CodeBlocks v12.11 与 MinGW 和 Irrlicht v1.8 引擎一起使用。我设置正确。在我的电脑上还有一个安装了 MinGW 的 Qt。是否有可能发生冲突？

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?

我将编译器配置为C:\CodeBlocks\MinGW. 每个文件（设置中显示了一些）都位于 下bin，除了make.exe. 这是正常的吗？

The Auto-detect button also suggests the path above.

自动检测按钮也建议上面的路径。

回答by

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.

1. 转到您的 MinGW 文件夹（应该是 C:\MinGW）
2. 打开 bin 文件夹。
3. 应该有一个名为 libstdc++-6.dll 的文件
4. 将其复制到与可执行文件相同的目录中。

That should work...

那应该工作...

回答by Devolus

The reason why this happens is because there can be a libstdc++-6.dllalso in the WINDOWS\System32directory (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 PATHvariable in such a way that your MingW\bindirectory is before the Windows system directory, replace the existing version with the newer one or copy the dll to the exectuable folder.

之所以出现这种情况的原因是因为可以有libstdc++-6.dll同样的WINDOWS\System32目录（或一些其他地方，它可以通过PATH中找到）。特别是当您使用不同版本的 MingW 时。因此，解决方案是更改环境PATH变量，使您的MingW\bin目录位于 Windows 系统目录之前，将现有版本替换为较新的版本或将 dll 复制到 exectuable 文件夹。

回答by M.M

These errors are caused by mismatched DLLs.

这些错误是由不匹配的 DLL 引起的。

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 .exefile being run.

对于问题中的消息，它是 的不正确版本libstdc++-6.dll，但您可以看到该消息指的是使用各种版本的 gcc for Windows 构建的其他 DLL；甚至提到.exe正在运行的文件。

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

• basic_string|char_traits...- 对于 C++11，有一个突破性的 ABI 更改为 std::string
• __gxx_personality_v0- 我相信这与正在使用的异常实现有关（Windows 的 gcc 可以使用各种 Dwarf2、Win32-SEH、SJLJ 等）

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

如果由一种编译器编译的应用程序链接到由不同编译器编译的 DLL，您将看到此消息。

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 lddif you have Cygwin or similar installed.

要查看找到的可执行文件的 DLL 列表，您可以在 Dependency Walker 中打开该可执行文件并启用“完整路径”选项。ldd如果您安装了 Cygwin 或类似软件，另一种方法是使用。

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

最常见的罪魁祸首是libstdc++-6.dll。不幸的是，ABI 的变化并没有伴随着 libstdc++ 版本号的变化；并且这不是异常模式出现在文件名中的默认行为。（如果自己构建 MinGW，您可以更改这些内容）。

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-*.dllis another one to look out for.

我建议检查 Dependency Walker 找到的每个 DLL，并确保它从您构建可执行文件的同一个 MinGW 版本中找到那些。libgcc-s-*.dll是另一个需要注意的。

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.

事实上，我建议不要在系统路径上安装任何这些 DLL。对于开发，我为我正在编译的同一个编译器加载了一个指向 DLL 的路径；对于部署，我将 DLL 与每个可执行文件捆绑在同一目录中，因为运行时 DLL 搜索始终首先检查该目录。这样就没有机会找到恰好在系统搜索路径上的旧 DLL。

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

（2019 年更新这些天我倾向于使用静态链接，因为部署更大的文件比陷入 DLL 地狱更不是问题）。

See also:

也可以看看：

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

• __gxx_personality_v0 有什么用？
• 解决该问题的另一个建议是使用静态链接，以便您的二进制文件首先不依赖于这些 DLL。

回答by Cao Phan Thanh

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.

当我在我的案例中分析这个时，我意识到系统路径配置中还有 2 个版本的 libstdc++-6.dll。一个在 mingw64 中，另一个在 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.

我的解决方案很简单：
我将 postgres 版本向下移动到 mingw64 版本以下。它完美地工作。

回答by taki

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

将 mingw\bin 中找到的 libstdc++-6.dll 复制到 windows\system32 祝你好运