Точка входа процедуры __gxx_personality_v0 не может быть расположена

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

Я продолжаю получать эту ошибку, если я хочу запустить приложение Irrlicht С++ Console в 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. Это нормально?

Кнопка Auto-detect также предлагает путь выше.

Ответы

Ответ 1

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

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

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

Ответ 2

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

Ответ 3

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

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

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

basic_string|char_traits... - для С++ 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).

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

Для чего нужен __gxx_personality_v0?
Другим предложением для устранения проблемы является использование статического связывания, чтобы ваш двоичный файл не зависел от этих библиотек.

Ответ 4

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

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

Мое решение простое:
Я перемещаю вниз версию postgres ниже версии mingw64. И это работает отлично.

Ответ 5

copy libstdС++ - 6.dll найдено в mingw\bin для windows\system32 удачи

Ответ 6

the procedure entry point __gxx_personality_v0 could not be located in the 
dynamic link library

Когда у меня возникла ошибка компоновщика через #include <vector>, я скопировал файл libstdc++-6.dll из MinGW\bin в Windows\SysWOW64, потому что копирование файла в WINDOWS\System32 не работало. Я подозреваю, что эта конкретная ошибка вызвана несоответствием версии битовой системы Windows между IDE Codelite и компилятором MinGW. Я должен был установить MinGW-w64 и установить его в качестве пути в IDE, но вместо этого на моем диске ОС (C :) есть mingw32.