Russian Qt Forum

Написал приложение, и dll'ку. Приложение собрал с помощью g++, dll - с помощью msvc. В результате, приложение не хочет грузить dll'ку (QLibrary::load()). Если для сборки приложения тоже использовать msvc, то все нормально - dll'ка грузится. Вопрос: как написать, с использованием Qt, dll'ку, которую можно будет загружать любым приложением, в независимости от того, чем собрано оно и сама dll'ка?

Попробуй поиграться Calling convention options: __stdcall должен быть.

В общем случае с использованием классов - IMHO никак - забодаешься с разными косяками бороться .... особенно весело получаеться, когда используються разные менеджеры памяти :( (new из одной rtl а delete из другой).....

Можно подробнее, что именно нужно сделать?

Ограничения:
Нужно чтобы dll-ка экспортировала только pure C функции.
Все функции должны быть объявлены как extern "C"
Параметры и возвраты должны быть или простые типы, или указатели (возможно ссылки) на структуры (по значению структуры передавать/возвращать нельзя)
Для каждой функции нужно явно указать соглашение о вызове (calling convention) например __stdcall или __ccall
Если передаёшь/возвращаешь указатели/ссылки на структуры, то нужно убедиться, что совпадает выравнивание.
Исключения не должны вылетать за пределы dll-ки, и колбеки, которые использует dll-ка не должны их генерить.

Память, выделенная в dll должна освобождаться там же.
dll Не должна пытаться освободить переданную ей память.
(Исключение составляет память выделенная функциями WinApi)

Про хорошее:
Можно передавать интерфейсы - пустые структуры содержащие только чисто виртуальные функции. ;-)

Смысл такой: имеется интерфейс, и имеется класс, который от него унаследован. Функции, которые экспортируются выглядят так:


где VideoGrabber наследован от IVideoGrabber.

Где не так? Что доделать?

Name mangling? Использовать для экспортируемых функций cdecl и extern "C".

extern "C" используется, посмотрите внимательнее на код, где прописать cdecl?

Народ , не забудте о простой вещи - если и длл и прога используют ту-же Qt - получиться ахинея - они будут ссылаться на _разные_ библиотеки с одним названием ....

extern "C" {
	__declspec(dllexport)  IVideoGrabber* newInstance() {
		return new VideoGrabber;
	}
	__declspec(dllexport)  void destroyInstance(IVideoGrabber *vgb) {
		delete vgb;
	}
}

Там же, где и происходит экспорт.
extern "C" нужно не для definition, а для declaration. К примеру:
Причем учти, что могут быть проблемы, если один из параметров функции или возвращаемое значения - указатель на шаблонный класс, и т.д., в этом случае даже эти штучки с calling convention не помогут, компайлер заманглит имена до не узнаваемости. Лучше уж просто использовать указатели на  void.

ИМХО если у QCasper-а не грузится сама либа в QLibrary::load(), то соглашения о вызове и т.д. тут не при чём. Т.е. до resolv дело ещё не дошло.
Дело или в самой DLL, тогда я б посоветовал создать пустую DLL c DllMain визардом MSVC и попытаться загрузить её.
Ну или дело в путях, в Qt и т.д.! :)

Ага, а после того как для сборки DLL начинаю использовать MSVC, то пути сразу становятся нормальными и Qt выпрямляется? :)

не помогло... кстати IVideoGrabber - наследник QObject, может быть это пагубно влияет? :)

МЯФ !!!!! У тебя форточки пытаються работать с двумя разными копиями qtcore Как с одной :) И как ты себе это представляешь ? Твоя прога грузит свой вариант qt собраный mingw , а dll требует qt собраный msvc и чего получиться ? + про рантайм vs не забудь (если ms 2005 - то еще .net framework) ....

ЗЫ А на куя такие танцы с бубнами ? не проще собрать две dll из одного кода , но с разными именами ?

Дело в том, что dll нельзя собрать с помощью g++, там код представляет собой помесь Qt и DirectShow, a g++ такие вещи не умеет.

Ну тады флаг в руки ;) IMHO - занятие бесполезное так-как ABI у gcc и vs все-таки разный :(
Хотя - если удасться добиться устойчивой работы такого - ставлю ящик пыва ;)

А чего именно не умеет g++ в DirectShow? ATL?

Я с этим вопросом особо не разбирался, но факт тот, что не умеет.
Вот, что ответили в рассылке: http://lists.trolltech.com/qt-interest/2007-08/thread00984-0.html
Вот местное обсуждение: http://prog.org.ru/forum/index.php/topic,6169.0.html Кстати здесь Ваша же цитата:

Попробуй заменить пакет w32 на последний - w32api-3.10.tar.gz
И попробуй собрать dll-ку мингвой, убрав все ссылки на PSDK.
Если DirectShow не последний, может и соберётся...

Если нет - тогда остаётся попытайся разделить вынести всё Qt из dll-ки, оставив только DirectShow, ну и экспортировать из неё только чистые С функции и интерфейсы...

мне почему то кажется, что это плохо :) Интерфейс не должен иметь членов, кроме vtable