punkt wejścia procedury GXX v0 nie mógł być zlokalizowany
Uwaga wydawcy: komunikaty o błędach podobne do "punkt błędu procedury _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ nie może być zlokalizowany w bibliotece dynamic link libstdc++-6.dll" mają tę samą przyczynę i te same rozwiązania mają zastosowanie.
Ciągle pojawia się ten błąd, jeśli chcę uruchomić moją aplikację konsolową Irrlicht C++ 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 jest też Qt zainstalowany z MinGW. Czy to możliwe, że istnieje konflikt?
To jest 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 na C:\CodeBlocks\MinGW.
Każdy plik (niektóre są pokazane w Ustawieniach) znajduje się pod bin, z wyjątkiem make.exe. Czy to normalne?
Przycisk Automatycznego Wykrywania sugeruje również ścieżkę powyżej.
5 answers
Ja też miałem ten problem. To mi to naprawiło:
- Przejdź do folderu MinGW (powinno być C:\MinGW)
- Otwórz folder bin.
- powinien być plik o nazwie libstdc++-6.dll
- Skopiuj to do tego samego katalogu co plik wykonywalny.
To powinno zadziałać...
Powodem, dla którego tak się dzieje, jest to, że może być libstdc++-6.dll również w katalogu WINDOWS\System32 (lub w innej lokalizacji, gdzie można go znaleźć poprzez PATH). Zwłaszcza, gdy używasz różnych wersji MingW. Rozwiązaniem jest więc albo zmiana zmiennej środowiskowej PATH w taki sposób, że katalog MingW\bin znajduje się przed katalogiem systemowym Windows, zastąpienie istniejącej wersji nowszą lub skopiowanie biblioteki dll do folderu wykonywalnego.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-04-03 12:35:56
Te błędy są spowodowane niedopasowanymi bibliotekami DLL.
Dla wiadomości w pytaniu jest to nieprawidłowa Wersja libstdc++-6.dll, ale można zobaczyć komunikat odnoszący się do innych bibliotek DLL, które zostały zbudowane z różnych wersji gcc Dla Windows; a nawet wspominając o uruchomionym pliku .exe.
Oto konkretne zmiany:
-
basic_string|char_traits...- w C++11 nastąpiła zmiana ABI nastd::string -
__gxx_personality_v0- uważam, że ma to związek z tym, że implementacja wyjątków jest w użyciu (gcc Dla Windows może używać różnych Dwarf2, Win32-SEH, Sjlj itp.)
Zobaczysz ten Komunikat, jeśli aplikacja skompilowana przez jeden smak kompilatora łączy się z biblioteką DLL skompilowaną przez inny smak.
Aby zobaczyć listę znalezionych bibliotek DLL dla pliku wykonywalnego, możesz otworzyć plik wykonywalny w Walkerze zależności i włączyć opcję "pełne ścieżki". Innym sposobem jest użycie ldd, Jeśli masz zainstalowany Cygwin lub podobny.
Najczęstszym winowajcą jest libstdc++-6.dll. Niestety ABI zmiana nie była powiązana ze zmianą numeru wersji libstdc++; i nie jest to domyślne zachowanie trybu wyjątku, który pojawia się w nazwie pliku. (Możesz zmienić te rzeczy, jeśli sam budujesz MinGW).
Zalecałbym sprawdzenie każdej biblioteki DLL znalezionej przez Dependency Walker i upewnienie się, że znajduje te z tej samej kompilacji MinGW, z którą zbudowałeś swój plik wykonywalny. libgcc-s-*.dll jest kolejnym, na który warto zwrócić uwagę.
W rzeczywistości Polecam nie mieć żadnego z tych bibliotek DLL na ścieżce systemowej. dla dewelopera Ładuję ścieżkę do bibliotek DLL dla tego samego kompilatora, z którym kompiluję; a dla wdrożenia pakuję biblioteki DLL do tego samego katalogu, co każdy plik wykonywalny, ponieważ runtime DLL search zawsze sprawdza ten katalog jako pierwszy. Wtedy nie ma szans na znalezienie starej biblioteki DLL, która znajduje się na ścieżce wyszukiwania systemowego.
(Update 2019 w dzisiejszych czasach zazwyczaj używam statycznego linkowania, ponieważ wdrożenie większego pliku jest mniejszym problemem niż utknięcie w DLL-hell).
Zobacz też:
- do czego służy_ _ GXX _ osobowość _ v0?
- kolejną sugestią rozwiązania problemu jest użycie statycznego linkowania , aby Twój plik binarny nie był zależny od tych bibliotek DLL.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-09-25 12:39:09
Kiedy analizowałem to w moim przypadku, zdałem sobie sprawę, że są jeszcze 2 wersje libstdc++-6.dll w konfiguracji ścieżki systemowej. Jeden znajduje się w mingw64, a drugi w postgres.
Problem w tym, że nie są takie same, ich rozmiar też jest inny.
Moje rozwiązanie jest proste:
Przenoszę wersję postgres poniżej wersji mingw64.
I działa idealnie.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2019-08-31 09:23:40
Skopiuj libstdc++-6.dll znaleziony w mingw \ bin to windows \ system32 powodzenia
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-05-01 18:34:42