procedura punkt wejścia __gxx_personality_v0 nie może znajdować się

Question

redakcji: komunikaty o błędach podobne do „Chodzi o błędzie procedura _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ nie może znajdować się w bibliotece dołączanej dynamicznie libstdc++-6.dll” mają tę samą przyczynę i zastosować te same rozwiązania.

---

Wciąż dostaję ten błąd, jeśli chcę uruchomić mój Irrlicht C++ konsoli aplikacji w systemie Windows:

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

Używam CodeBlocks v12.11 z MinGW i silnikiem Irrlicht v1.8 . Ustawiłem to poprawnie. Na moim komputerze istnieje również Qt zainstalowany z MinGW. Czy to możliwe, że dochodzi do konfliktu?

Jest to kod źródłowy:

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

skonfigurowałem kompilator C:\CodeBlocks\MinGW. Każdy plik (niektóre są wyświetlane w Ustawieniach) znajduje się pod bin, z wyjątkiem make.exe. Czy to normalne?

Przycisk Auto-detect sugeruje również powyższą ścieżkę.

Answer 1

Miałem również ten problem. To naprawić to dla mnie:

1. przejdź do folderu MinGW (powinno być C: \ MinGW)
2. Otwórz folder bin.
3. Powinien istnieć plik o nazwie libstdC++ - 6.dll
4. Skopiuj ten plik do tego samego katalogu, w którym znajduje się plik wykonywalny.

To powinno działać ...

Answer 2

Powodem dlaczego tak się dzieje dlatego, że nie może być libstdc++-6.dllWINDOWS\System32 również w katalogu (lub w jakimś innym miejscu, gdzie można je znaleźć poprzez PATH). Zwłaszcza, gdy używasz różnych wersji MingW. Rozwiązaniem jest albo zmiana zmiennej środowiskowej PATH w taki sposób, aby Twój katalog MingW\bin był przed katalogiem systemu Windows, zastąpienie istniejącej wersji nowszym lub skopiowanie biblioteki dll do folderu, który można wyświetlić.

Answer 3

kopia libstdC++ - 6.dll znaleźć w mingw \ bin do windows \ system32 powodzenia

Answer 4

Błędy te są spowodowane przez niedopasowane DLL.

Dla wiadomości w pytaniu jest to niepoprawna wersja libstdc++-6.dll, ale można zobaczyć komunikat odnoszący się do innych bibliotek DLL, które zostały zbudowane z różnymi wersjami gcc dla Windows; a nawet wspomnienie o uruchomionym pliku .exe.

Konkretne zmiany są tu:

• basic_string|char_traits... - dla C++ 11 doszło do zerwania ABI zmiana std::string
• __gxx_personality_v0 - Wierzę, że to ma coś wspólnego z których realizacja Wyjątkiem jest w użyciu (gcc dla Windows może używać różnych programów Dwarf2, Win32-SEH, SJLJ itp.)

Ta wiadomość pojawi się, jeśli aplikacja skompilowana przez jeden smak kompilatora będzie łączyła się z biblioteką DLL skompilowaną przez inne flavo ur.

Aby zobaczyć listę znalezionych plików DLL dla pliku wykonywalnego, można otworzyć plik wykonywalny w programie Dependency Walker i włączyć opcję "Pełna ścieżka". Innym sposobem jest użycie ldd, jeśli masz zainstalowane Cygwin lub podobne.

Najczęstszym winnym jest libstdc++-6.dll. Niestety zmiana ABI nie była powiązana ze zmianą numeru wersji libstdC++; i nie jest domyślnym zachowaniem trybu wyjątku w nazwie pliku. (Możesz zmienić te rzeczy, jeśli sam budujesz MinGW).

Polecam sprawdzenie każdej znalezionej biblioteki DLL przez Dependency Walker i upewnienie się, że znajduje ona te z tej samej wersji gry MinGW, z której zbudowałeś swój plik wykonywalny. libgcc-s-*.dll to kolejny, na który należy zwrócić uwagę.

W rzeczywistości nie polecam żadnej z tych bibliotek DLL na ścieżce systemowej. Dla rozwoju ładuję PATH do bibliotek DLL dla tego samego kompilatora, z którego kompiluję; i dla wdrożenia pakuję pliki DLL w tym samym katalogu, co każdy plik wykonywalny, ponieważ wyszukiwanie biblioteki DLL w środowisku wykonawczym zawsze najpierw sprawdza ten katalog. Wtedy nie ma szansy na znalezienie starej biblioteki DLL znajdującej się w ścieżce wyszukiwania systemu.