找不到过程入口点__gxx_personality_v0

the procedure entry point __gxx_personality_v0 could not be located

本文关键字：gxx v0 personality 过程 入口 找不到      更新时间：2023-10-16

编者注：类似于"无法在动态链接库中找到过程错误点_ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ libstdc++-6.dll"的错误消息具有相同的原因，并且相同的解决方案适用。

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

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

我正在使用带有MinGW和Irrlicht v1.8引擎的CodeBlocks v12.11。我设置正确。在我的电脑上，还安装了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:CodeBlocksMinGW .每个文件（设置中都显示了一些）都位于 bin 下，除了 make.exe .这正常吗？

"自动检测"按钮还会建议上面的路径。

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

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

这应该可以...

发生这种情况

的原因是，在WINDOWSSystem32目录中（或通过 PATH 可以找到它的其他位置）中也可能有一个libstdc++-6.dll。特别是当您使用不同版本的 MingW 时。因此，解决方案是更改环境PATH变量，使MingWbin目录位于Windows系统目录之前，将现有版本替换为较新的版本或将dll复制到可执行文件夹。

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

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

这里的具体变化是：

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

如果由一种编译器编译的应用程序链接到由另一种风格编译的 DLL，则会看到此消息。

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

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

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

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

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

另请参阅：

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

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

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

我的解决方案很简单：
我将 postgres 的版本移到 mingw64 版本下方。而且它工作得很好。

将 libstdc++-6.dll 在 mingw\bin 中找到到 Windows\system32祝你好运

相关文章：