[РЕШЕНО, но так себе] Грузит не ту DLL

[Torvald]

На самом деле это delphi проект, который грузить dll написанную на Qt, и вот при загрузке этой длл возникает эта ошибка.

Эмм... а разве так можно? Откуда дельфи знает про Qt? 
Или имеется ввиду, что dll-ка написана в QtCreator без использования Qt-шных классов?

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

[gil9red]

На самом деле это delphi проект, который грузить dll написанную на Qt, и вот при загрузке этой длл возникает эта ошибка.

Эмм... а разве так можно? Откуда дельфи знает про Qt? 
Или имеется ввиду, что dll-ка написана в QtCreator без использования Qt-шных классов?

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

А как же бинарная совместимость? Если компиляторы dll и exe разные используются?

[Torvald]

На самом деле это delphi проект, который грузить dll написанную на Qt, и вот при загрузке этой длл возникает эта ошибка.

Эмм... а разве так можно? Откуда дельфи знает про Qt?  
Или имеется ввиду, что dll-ка написана в QtCreator без использования Qt-шных классов?

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

А как же бинарная совместимость? Если компиляторы dll и exe разные используются?

Это важно только на стадии линковки. При динамической загрузке не важно какой там компилятор - машинный код же. Хоть на прологе пиши длл

[Авварон]

А как же бинарная совместимость? Если компиляторы dll и exe разные используются?

ABI С стандартизован, как и code conventions. Можно из дллки отрезолвить сишную функцию (с правильным code convention) и вызвать её.
Неважно из какого языка.
Плюсовую функцию нельзя, потому что mangnling имен не стандартизован и неизвестно, как она реально называется.

[Igors]

Вот в это время (скорее всего при создании QApplication) начинается подгрузка кутишный библиотек, которые лежат рядом. Все грузятся нормально, кроме libstdc++-6.dll.

Обычно это не так, либы грузятся до загрузки модуля который их требует. Если хоть с одной не вышло - до main дело не дойдет. В консоли отладчика (по крайней мере на MSVC) показываются загружаемые модули. Я бы начал с выяснения кому нужна эта libstdc++-6.dll. Сделал бы тестовое приложение (абы запустилось) и посмотрел бы перед какой либой грузится libstdc.

[Bepec]

Неее, половина Qt теперь на плагинах построена.
Которые занимаются непосредственным резолвингом функций уже после загрузки приложения. Там у них тупо вбито "LoadLibrary" и "GetProcAddress".
Поэтому даже загрузка приложения != подгрузка всех библиотек. Сам с этим сталкивался, когда с бдшками работал и сетью.

[Igors]

Неее, половина Qt теперь на плагинах построена.
Которые занимаются непосредственным резолвингом функций уже после загрузки приложения. Там у них тупо вбито "LoadLibrary" и "GetProcAddress".

Для данной либы (libstdc) слишком много пришлось бы резолвить

Проблема в том что неубогое Вындоуз наверное не позволит загрузить др либу хоть откуда если либа с таким именем уже в памяти процесса. Придется как-то переименовывать (libstdZ что ли) и править ссылки во всех использующих либах. Уродство конечно. Или линковать всю свою либу статычно чтобы избавиться от зависимости libstdc

Впрочем послушаем тех кто утверждал что Вындоуз впереди планеты всей 

[Пантер]

Мда, в Винде действительно геморрой с dll. В Линухе все намного удобнее - LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./prog и все работает.

[lit-uriy]

>>Вындоуз наверное не позволит загрузить др либу хоть откуда если либа с таким именем уже в памяти процесса.
а откуда она появилась в памяти процесса?
Это типа такой зоопарк у процесса что ему одновременно нужны DLL-ки с одинаковым именем, но совершенно не совместимые между собой?

[Bepec]

А Linux позволяет загрузить в приложение 2 версии одной Dll? Рили?

[Igors]

А Linux позволяет загрузить в приложение 2 версии одной Dll? Рили?

Про линукс ничего не скажу, а OSX точно позволяет

[Torvald]

Хм, а можно как то узнать какие переменные окружения задает приложение при запуске? И как узнать какая  именно длл подгружается, по какому пути?

[Torvald]

Нашел откуда грузилась библиотека. Из некой FileZilla. Почему оттуда - непонятно, видимо родительское приложение как то неявно туда указывает или его переменные окружения не определены, а для FileZilla установлены глобально

Короче говоря основное приложение загружает кучу всяких модулей. Часть из них используют одну версию libstdc++-6.dll, часть - другую. Что делать в этой ситуации не понятно. Это какая то каша из длл которые ссылаются на другие длл которые ссылаются на общие длл но разных версий %)

[Torvald]

Короче я просто переименовал libstdc++-6.dll в libstdc++-X.dll и заменил все ее упоминания во всех своих зависимых длл. Очень грязный хак, но как быстрое временное решение пока сойдет.

Всем большое спасибо за помощь. Вот уж точно dll hell :c

[Igors]

Короче я просто переименовал libstdc++-6.dll в libstdc++-X.dll и заменил все ее упоминания во всех своих зависимых длл. Очень грязный хак, но как быстрое временное решение пока сойдет.

Очень может быть что на данном ОС лучшего решения и объективно нет. Так что не переживайте и

Нет ничего более постоянного чем временное