не удалось найти точку входа в процедуру __gxx_personality_v0

Примечание редактора: сообщения об ошибках, похожие на «Точка ошибки процедуры _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEC1EPKcRKS3_ не может быть найдена в библиотеке динамической компоновки libstdc++-6.dll», имеют ту же причину и применяются те же решения.


Я продолжаю получать эту ошибку, если хочу запустить консольное приложение Irrlicht C ++ в Windows:

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. Настроил правильно. На моем компьютере также установлен Qt с MinGW. Возможен ли конфликт?

Это исходный код:

#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. Каждый файл (некоторые из них показаны в настройках) находится под bin, кроме make.exe. Это нормально?

Кнопка «Автоопределение» также предлагает путь, указанный выше.


person Niklas    schedule 06.09.2013    source источник
comment
Вы не забыли редактировать Настройки- ›Каталоги поиска на вкладке компоновщика? (чтобы компоновщик мог найти двоичные файлы.)   -  person ryyker    schedule 08.09.2013


Ответы (5)


У меня тоже была эта проблема. Это исправило это для меня:

  1. Перейдите в папку MinGW (она должна быть C: \ MinGW)
  2. Откройте папку bin.
  3. Должен быть файл с названием libstdc ++ - 6.dll
  4. Скопируйте это в тот же каталог, что и ваш исполняемый файл.

Это должно сработать ...

person Community    schedule 08.12.2013
comment
отличный ответ, который сэкономил мне миллионы энергии - person Stefano Mtangoo; 03.02.2016
comment
что я могу сделать, если у меня нет libstdc ++ - 6.dll в папке minGW? - person StefanTflch; 19.07.2016
comment
Хотя это выбор Хобсона. Скопируйте 1M dll в каталог с исполняемым файлом или живите с исполняемым файлом размером 500K после strip -s. (это фактически добавляет к общему размеру, чтобы скопировать dll) - person David C. Rankin; 24.08.2019
comment
обратите внимание, что другой вариант - использовать статическое связывание, чтобы ваш двоичный файл в любом случае не зависел от этих DLL. - person M.M; 25.09.2019
comment
Если кто-то нашел это решение для устранения проблемы, все равно будьте осторожны, поскольку двоичный файл также может зависеть от других DLL (таких как libgcc_s, libwinpthread) с более тонкими проблемами во время выполнения, если используется неправильная версия - я бы посоветовал убедиться, что все зависимости проверены, подробности см. в моем ответе - person M.M; 25.09.2019
comment
@StefanTflch Он должен быть там, ты в \ bin? - person Le mouton vert; 14.04.2020

Причина, по которой это происходит, заключается в том, что libstdc++-6.dll также может быть в каталоге WINDOWS\System32 (или в другом месте, где его можно найти через PATH). Особенно при использовании разных версий MingW. Таким образом, решение состоит в том, чтобы либо изменить переменную окружения PATH таким образом, чтобы ваш MingW\bin каталог находился перед системным каталогом Windows, заменить существующую версию на более новую или скопировать dll в исполняемую папку.

person Devolus    schedule 03.04.2014
comment
Я бы рекомендовал удалить библиотеки DLL MinGW из системных путей и развернуть правильную версию с каждым развернутым исполняемым файлом. Использует больше места на диске, да, но никаких шансов на подобную проблему - person M.M; 14.11.2017
comment
Дубликат libstdc++-6.dll также может храниться в каталоге установки Git под mingw64\bin и / или mingw64\libexec\git-core. Я просто удалил эти файлы, а g++ и git по-прежнему работают - person Pokechu48; 21.11.2020

Эти ошибки вызваны несовпадением библиотек DLL.

Что касается сообщений в вопросе, это неправильная версия libstdc++-6.dll, но вы можете увидеть сообщение, относящееся к другим библиотекам DLL, которые были созданы с различными версиями gcc для Windows; и даже упоминание о запущенном .exe файле.

Конкретные изменения здесь:

  • basic_string|char_traits... - для C ++ 11 произошло нарушение ABI, изменившееся на std::string
  • __gxx_personality_v0 - Я считаю, что это связано с тем, какая реализация исключения используется (gcc для Windows может использовать различные из Dwarf2, Win32-SEH, SJLJ и т. Д.)

Вы увидите это сообщение, если приложение, скомпилированное с помощью одного варианта компилятора, ссылается на библиотеку DLL, скомпилированную с помощью другого варианта.

Чтобы увидеть список найденных DLL для исполняемого файла, вы можете открыть исполняемый файл в Dependency Walker и включить параметр «Полные пути». Другой способ - использовать ldd, если у вас установлен Cygwin или аналогичный.

Самый частый виновник - libstdc++-6.dll. К сожалению, изменение ABI не было связано с изменением номера версии libstdc ++; и это не поведение по умолчанию, когда режим исключения появляется в имени файла. (Вы можете изменить эти вещи, если собираете MinGW самостоятельно).

Я бы рекомендовал проверить каждую DLL, найденную Dependency Walker, и убедиться, что она находит те из той же сборки MinGW, с которой вы создали свой исполняемый файл. libgcc-s-*.dll - еще один, на который стоит обратить внимание.

Фактически, я бы рекомендовал не иметь ни одной из этих библиотек DLL в системном пути. Для разработки я загружаю PATH в библиотеки DLL для того же компилятора, с которым я компилирую; а для развертывания я помещаю библиотеки DLL в тот же каталог, что и каждый исполняемый файл, потому что поиск DLL во время выполнения всегда сначала проверяет этот каталог. Тогда нет никаких шансов найти старую DLL, которая случайно попала в системный путь поиска.

(Обновление 2019 В наши дни я обычно использую статическое связывание, потому что развертывание файла большего размера - меньшая проблема, чем застревание в аду DLL).

Смотрите также:

person M.M    schedule 14.11.2017

Когда я проанализировал это в моем случае, я понял, что есть еще 2 версии libstdc ++ - 6.dll в конфигурации системного пути. Один находится в mingw64, а другой - в postgres.

Проблема в том, что они не одинаковые, у них тоже разные размеры.

Мое решение простое:
Я опускаю версию postgres ниже версии mingw64. И работает отлично.

person Cao Phan Thanh    schedule 31.08.2019

скопируйте libstdc ++ - 6.dll из mingw \ bin в windows \ system32 удачи

person taki    schedule 01.05.2016