找不到过程入口点 __gxx_personality_v0答案

【问题标题】：the procedure entry point __gxx_personality_v0 could not be located找不到过程入口点 __gxx_personality_v0
【发布时间】：2021-06-01 22:04:00
【问题描述】：

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

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

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

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

这是源代码：

#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;
}

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

“自动检测”按钮还会提示上述路径。

【问题讨论】：

您记得在链接器选项卡下编辑设置->搜索目录吗？（因此链接器可以找到二进制文件。）

标签： c++ qt mingw codeblocks irrlicht

【解决方案1】：

我也有这个问题。这为我修复了它：

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

应该可以的...

【讨论】：

很好的答案为我节省了大量的精力
如果我在 minGW 文件夹中没有 libstdc++-6.dll 怎么办？
虽然这有点像霍布森的选择。将 1M 的 dll 复制到包含您的可执行文件的目录中，或者在 strip -s 之后使用 500K 的可执行文件。（它实际上增加了复制 dll 的整体大小）
请注意，另一种选择是使用静态链接，这样您的二进制文件就不会依赖这些 DLL
如果有人找到这个解决方案来解决问题，那么仍然要小心，因为二进制文件也可能依赖于其他 DLL（例如libgcc_s、libwinpthread），如果使用了错误的版本——我建议确保检查所有依赖项，详情请参阅我的答案

【解决方案2】：

发生这种情况的原因是因为libstdc++-6.dll 也可以在WINDOWS\System32 目录中（或在其他可以通过PATH 找到的位置）。特别是当您使用不同版本的 MingW 时。所以解决办法是要么改变环境PATH变量，使你的MingW\bin目录在Windows系统目录之前，用较新的版本替换现有版本，或者将dll复制到可执行文件夹。

【讨论】：

我建议从系统路径中删除 MinGW DLL，并为每个部署的可执行文件部署正确的版本。使用更多磁盘空间是的，但不会出现此类问题
libstdc++-6.dll的副本也可以存储在mingw64\bin和/或mingw64\libexec\git-core下的Git安装目录中。我只是删除了这些文件，g++ 和 git 仍然有效

【解决方案3】：

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

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

这里的具体变化是：

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

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

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

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

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

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

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

另见：

What is __gxx_personality_v0 for?
解决问题的另一个建议是use static linking，这样您的二进制文件就不会首先依赖这些 DLL。

【讨论】：

【解决方案4】：

当我在我的案例中进行分析时，我意识到系统路径配置中还有 2 个版本的 libstdc++-6.dll。一个在 mingw64 中，另一个在 postgres 中。

问题是它们不一样，它们的大小也不同。

我的解决方案很简单：
我将 postgres 的版本降低到 mingw64 版本以下。而且效果很好。

【讨论】：

【解决方案5】：

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

【讨论】：