it-swarm.com.de

der Prozedureintrittspunkt __gxx_personality_v0 konnte nicht gefunden werden

Anmerkung des Herausgebers: Fehlermeldungen ähnlich wie "Der Prozedurfehlerpunkt _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ konnte nicht in der Dynamic Link Library libstdc++-6.dll gefunden werden" haben dieselbe Ursache und die gleichen Lösungen.


Ich erhalte diese Fehlermeldung immer wieder, wenn ich meine Irrlicht C++ - Konsolenanwendung in Windows ausführen möchte:

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

Ich verwende CodeBlocks v12.11 mit MinGW und der Irrlicht v1.8 Engine. Ich habe es richtig eingerichtet. Auf meinem Computer ist auch ein Qt mit MinGW installiert. Ist es möglich, dass es einen Konflikt gibt?

Dies ist der Quellcode:

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

Ich habe den Compiler für C:\CodeBlocks\MinGW..__ konfiguriert. Jede Datei (einige davon werden in den Einstellungen angezeigt) befindet sich unter bin, mit Ausnahme von make.exe. Ist das normal?

Die Schaltfläche Automatisch erkennen schlägt auch den Pfad vor.

26
Niklas

Ich hatte auch dieses Problem. Das hat es für mich behoben:

  1. Gehen Sie zu Ihrem MinGW-Ordner (sollte C:\MinGW sein)
  2. Öffnen Sie den Bin-Ordner.
  3. Es sollte eine Datei namens libstdc ++ - 6.dll geben
  4. Kopieren Sie dies in dasselbe Verzeichnis wie Ihre ausführbare Datei.

Das sollte funktionieren...

49
user2947761

Der Grund dafür ist, dass libstdc++-6.dll auch im WINDOWS\System32-Verzeichnis (oder an einem anderen Ort, wo es über PATH zu finden ist) vorhanden sein kann. Besonders wenn Sie unterschiedliche Versionen von MingW verwenden. Die Lösung besteht also entweder darin, die Umgebungsvariable PATH so zu ändern, dass Ihr MingW\bin-Verzeichnis vor dem Windows-Systemverzeichnis liegt, die vorhandene Version durch die neuere zu ersetzen oder die DLL in den ausführbaren Ordner zu kopieren.

15
Devolus

Diese Fehler werden durch nicht übereinstimmende DLLs verursacht. 

Bei den Nachrichten in der Frage handelt es sich um eine falsche Version von libstdc++-6.dll. Sie können jedoch die Nachricht sehen, die auf andere DLLs verweist, die mit verschiedenen Versionen von gcc für Windows erstellt wurden. und sogar die .exe-Datei erwähnt, die ausgeführt wird. 

Die spezifischen Änderungen hier sind:

  • basic_string|char_traits... - Für C++ 11 wurde die Änderung von ABI in std::string geändert.
  • __gxx_personality_v0 - Ich glaube, das hat mit der Ausnahme-Implementierung zu tun (gcc für Windows kann verschiedene von Dwarf2, Win32-SEH, SJLJ usw. verwenden)

Diese Meldung wird angezeigt, wenn eine Anwendung, die mit einem Compiler-Compiler kompiliert wurde, eine Verknüpfung zu einem DLL erstellt, der mit einem anderen Flavour kompiliert wurde. 

Um eine Liste der gefundenen DLLs für eine ausführbare Datei anzuzeigen, können Sie die ausführbare Datei in Dependency Walker öffnen und die Option "Full Paths" aktivieren. Eine andere Möglichkeit ist die Verwendung von ldd, wenn Cygwin oder ähnliches installiert ist.

Der üblichste Täter ist libstdc++-6.dll. Leider war die ABI-Änderung nicht mit einer Änderung der Versionsnummer von libstdc ++ gekoppelt. Es ist nicht das Standardverhalten, dass der Ausnahmemodus im Dateinamen angezeigt wird. (Sie können diese Dinge ändern, wenn Sie MinGW selbst bauen).

Ich würde empfehlen, jedes DLL zu überprüfen, das von Dependency Walker gefunden wurde, und sicherzustellen, dass es die Dateien aus demselben Build von MinGW findet, mit denen Sie Ihre ausführbare Datei erstellt haben. libgcc-s-*.dll ist ein weiterer, auf den Sie achten sollten.

In der Tat würde ich empfehlen, keine dieser DLLs auf dem Systempfad zu haben. Für die Entwicklung lade ich einen PATH in die DLLs des gleichen Compilers, mit dem ich kompiliere. und für die Bereitstellung gebündle ich die DLLs in demselben Verzeichnis wie jede ausführbare Datei, da die Laufzeitsuche DLL dieses Verzeichnis immer zuerst prüft. Dann besteht keine Chance, eine alte DLL zu finden, die sich zufällig in einem Systemsuchpfad befindet.

2
M.M

Als ich dies in meinem Fall analysierte, stellte ich fest, dass sich 2 weitere Versionen von libstdc ++ - 6.dll in der Systempfadkonfiguration befinden. Einer ist in Mingw64 und ein anderer ist in Postgres.

Das Problem ist, dass sie nicht gleich sind, auch ihre Größe ist unterschiedlich.

Meine Lösung ist einfach:
Ich gehe die Postgres-Version unter die mingw64-Version runter. Und es funktioniert einwandfrei.

1
Cao Phan Thanh

kopieren Sie libstdc ++ - 6.dll in mingw\bin unter Windows\system32 Viel Glück

0
taki