Пишу программу на Qt (Qt5.2, MinGW, WinXP). К ней подключаются Dll-ки, написанные, как на Qt, так и на C++Builder. DLLки писал как пустышки-заглушки, с минимальным функционалом для отладки. Пользовался QLibrary. Проблемы не возникали.

Но вот написал код для подключения новой ДЛЛки. И подключил существующую ДЛЛку, написанную на Билдере, которую используем уже много лет. Программа рушится. Причем в разные моменты времени. Иногда половину просчитает, но чаще раньше падает. То ошибку плавающей запятой вывалит, то еще какую..

Рушится даже если не выуживаю из ДЛЛки и, соответсвенно, не использую ни одну из импортируемых функций. Только делаю QLibrary::load.

Заново создал ДЛЛку-пустышку на Билдере. Рушится. Потом создал аналогичную пустышку на Qt. Не рушится. Потом убрал QLibrary, а вместо нее использую LoadLibrary. Перестали рушится Билдеровские пустышки.

На радостях запустил толстую ДЛЛку — опять рушится. Вычистил эту ДЛЛку до функций-пустышек — все равно рушится. Сделал еще один проект ДЛЛ на Билдере с пустышками, но с поддрежкой VCL(как и основная, толстая ДЛЛ) — рушится. Т.е. как бы виновата VCL?

Уже не знаю что и делать. Задача оч. ответсвенная. Помогите, пожалуйста.

Заметил странную особенность, что DllEntryPoint из ДЛЛки вызывается много раз, цепляясь не только к процессу, но и к потокам. Причем к потокам цепляется как-то странно, количество прицепов существенно не совпадает с количеством отцепов. Иногда вначале начинает отцепляться, хотя до этого не прицеплялся. Так должно быть?

В ДЛЛке на Билдере убрал поддержку VCL и поменял файловый ввод/вывод с fstream на fopen. Теперь не падает. Надолго ли?

Не понятно почему. Шаманство какое-то. Да и VCL, fstream жалко.

Здравствуйте, TYuD, Вы писали:

TYD>В ДЛЛке на Билдере убрал поддержку VCL и поменял файловый ввод/вывод с fstream на fopen. Теперь не падает. Надолго ли?

TYD>Не понятно почему. Шаманство какое-то. Да и VCL, fstream жалко.

Компилятор Builder-а вроде бы как бинарно несовместим с MSVC (и другими, которые с ним совместимы).
Я точно не знаю, поскольку я с ним дела не имел, но проверь просто, чтобы не мучиться.

1/29/2014 2:08 PM, MasterZiv пишет:

> Компилятор Builder-а вроде бы как бинарно несовместим с MSVC (и другими,
> которые с ним совместимы).
Когда это такое произошло? Раньше они были не совместимы и чтобы
состыковать одно с другим приходилось прилично пошаманить.
Но я уже бордандовской гадостью не пользуюсь давно, так что не подскажу,
ну и может там все изменилось.

Здравствуйте, Vzhyk, Вы писали:

V>Когда это такое произошло? Раньше они были не совместимы и чтобы
V>состыковать одно с другим приходилось прилично пошаманить.
V>Но я уже бордандовской гадостью не пользуюсь давно, так что не подскажу,
V>ну и может там все изменилось.

Билдера старый ВСВ5. От него пока не можем отказаться. Стыкую с Qt5. Имелся опыт, когда ДЛЛки на Qt без проблем цеплялись к exe-шнику на BCB. А сейчас — наоборот — ДЛЛки на Билдере, а экзэшник на Куте.

Здравствуйте, TYuD, Вы писали:

TYD>В ДЛЛке на Билдере убрал поддержку VCL и поменял файловый ввод/вывод с fstream на fopen. Теперь не падает. Надолго ли?

По идее, C ABI совместимы в разных компиляторах, а вот C++ ABI — нет. Очень похоже на то, что единственный путь скрестить ежа и ужа в вашем случае — использоать extern C между Borland5-dll и mingw-exe. В частности, после того как вы ушли от плюсового fstream к сишному fopen, заработало. Другой вопрос, приемлемо ли это в вашем случае.

1/31/2014 11:26 AM, TYuD пишет:

> Билдера старый ВСВ5. От него пока не можем отказаться. Стыкую с Qt5.
> Имелся опыт, когда ДЛЛки на Qt без проблем цеплялись к exe-шнику на BCB.
> А сейчас — наоборот — ДЛЛки на Билдере, а экзэшник на Куте.
В общем можно, без def файла не обойтись. Там все плывет: соглашения
вызова совпадают по названию, но не совпадают по тому, что делают.
Но, этим я занимался, именно тогда когда еще ВСВ5 был жив (около 10 лет
назад) и им пользовались и сейчас просто не вспомню.
Делал таблицу (на бумажке) соглашений вызовов для каждого компилятора и
нашел то, которое позволило обойтись def файлом.
О плюсовых возможностях можете забыть сразу, только С в интерфейсе либы.

Здравствуйте, visual_wind, Вы писали:

_>По идее, C ABI совместимы в разных компиляторах,
А вот здесь есть нюансы, в которых и спрятался большущий дьявол.

Здравствуйте, Vzhyk, Вы писали:

V>Делал таблицу (на бумажке) соглашений вызовов для каждого компилятора и
V>нашел то, которое позволило обойтись def файлом.
V>О плюсовых возможностях можете забыть сразу, только С в интерфейсе либы.
А вот еще через implib можно пойти, тоже получается. И у Багланда есть что-то аналогичное, не помню уже точно.

Здравствуйте, Vzhyk, Вы писали:

V>О плюсовых возможностях можете забыть сразу, только С в интерфейсе либы.

Если речь только об интерфейсе, то так и предполагалось, что интерфейс С-шный. А вот внутри ДЛЛки не хочется терять объекты. Вот VCL уже исключать начал..

V>Делал таблицу (на бумажке) соглашений вызовов для каждого компилятора и
V>нашел то, которое позволило обойтись def файлом.

def файл — это который в Qt? А чего там интересного можно указать, кроме имен экспоритуемых методов?

Здравствуйте, visual_wind, Вы писали:

_>По идее, C ABI совместимы в разных компиляторах, а вот C++ ABI — нет.

Что такое ABI?

_>единственный путь скрестить ежа и ужа в вашем случае — использоать extern C между Borland5-dll и mingw-exe.

Так и делаю.

_>В частности, после того как вы ушли от плюсового fstream к сишному fopen, заработало. Другой вопрос, приемлемо ли это в вашем случае.

Если бы только С-шный интерфейс был ограничением, то и сошло бы (так и планировалось). Но внутри ДЛЛки хочется объекты юзать. Вот потоки пришлось отрубить, VCL.. Уже неприятно. Но более волнует вопрос о том, сколько еще подводных камней?

Здравствуйте, Аноним, Вы писали:

А>А вот еще через implib можно пойти, тоже получается. И у Багланда есть что-то аналогичное, не помню уже точно.

У Борланда есть implib, а чем она поможет?

2/2/2014 12:03 PM, TYuD пишет:

> У Борланда есть implib, а чем она поможет?
Занимался я этим 10 лет назад и больше к поделию от багланда не
притрагивался. Все, что вспомнил, я написал, остальное читай сам. Или,
$2500 (мне достаточно) в месяц чистыми и я слажу в это для тебя.

Здравствуйте, TYuD, Вы писали:

TYD>Что такое ABI?
Об этом вкратце можно почитать здесь.

TYD>Если бы только С-шный интерфейс был ограничением, то и сошло бы (так и планировалось). Но внутри ДЛЛки хочется объекты юзать. Вот потоки пришлось отрубить, VCL.. Уже неприятно. Но более волнует вопрос о том, сколько еще подводных камней?

По идее, объекты внутри длл, собранной другим компилятором, использовать можно. Но перечислить все подводные очень сложно. Если у вас билдер.длл работала ранее, то наверняка там все нормально с соглашением о вызовах. Если у вас при этом:
— одинаковая разрядность обоих компиляторов
— все экспортируемое — extern C
— одинаковое выравнивание в структурах
— аккуратно обрабатываются исключения внутри длл, не давая им вылезти наружу в экзешник
— ресурсы (включая память), захваченные в экзешнике, не освобождаются в длл (и наоборот),

то больше посоветовать ничего не могу. Скорее всего, есть еще достаточно неучтенных проблем, которые вым придется решать опытным путем. Увы, только методом проб и ошибок.

Здравствуйте, visual_wind, Вы писали:

TYD>>Что такое ABI?
_>Об этом вкратце можно почитать...

Понятно

_>Скорее всего, есть еще достаточно неучтенных проблем, которые вым придется решать опытным путем. Увы, только методом проб и ошибок.

Вот еще заметил. Если одна ДЛЛка вызывает другую (откомпилированную другим компилятором), а та выводит ГУИ-сообщение, то программа падает. Пробовал ГУИ на Qt и ГУИ на Билдере. А вот если ГУИ-сообщение формирую только Виндовыми функциями (отключив VCL в Билдере), то работает. Может это связано с разными механизмами обработки сообщений?