Проблема с DLL
Если кто знает, в чет тут заморочка, - буду премного благодарен.
Статически подключаю к проекту DLL. Во время отладки программы все работает нормально. Но как только делаю окончательный билд (отключаю Linker page: "Create debug information", "Use dynamic RTL"; Packages page: "Build with runtime packages") и запускаю программу, то при выходе из нее выскакивает ошибка "Инструкция по такому-то адресу обратилась к памяти по эдакому адресу. Память не может быть 'read'." Причем если тот-же самый код использовать не из DLL, а вставить в виде юнита, то все работает нормально.
Если кто знает, в чет тут заморочка, - буду премного благодарен.
Дык если отключена опция "Use Dynamic RTL", то бибилотеки должны быть включены в код (советую включить эту опцию)
Дык если отключена опция "Use Dynamic RTL", то бибилотеки должны быть включены в код (советую включить эту опцию)
Советую внимательно прочитать хэлп по опции "Use Dynamic RTL":
"Use dynamic RTL means to use the RTL DLL, which is the DLL version of the Runtime Library in your application (or dll/package/ActiveX control). If you enable the option, the RTL code isn’t linked into your application, resulting in a smaller image, but you must distribute the RTL DLL with your application. This option defines the conditional define _RTLDLL."
Насколько я понимаю, там говорится примерно следующее: "Если опция включена, в проекте будут использоваться RTL DLL, но тогда их придется включать в дистрибутив. Если отключена - не придется, т.к. компоновщик включит необходимый код в .EXE".
Если кто знает, в чет тут заморочка, - буду премного благодарен.
Могу сказать почти со стопроцентной уверенностью - проблема в приеме/передаче AnsiString. Нужно или всегда использовать динамические библиотеки выполнения, или задействовать ShareMem.
Есть также два других сильнодействующих средства - инициализировать менеджер памяти DLL вручную или собрать собственную библиотеку времени выполнения. Если проект состоит из многих DLL, рекомендовано второе.
Могу сказать почти со стопроцентной уверенностью - проблема в приеме/передаче AnsiString.
Во избежание проблем я в DLL не использовал тип AnsiString. Правда из нее инициируются исключения, производные от Exception (у которого, как известно, в качестве типа аргумента конструктора используется AnsiString), но классы этих исключений определены в заголовочном файле и, следовательно, из DLL не экспортируются. Правда некотроые члены классов библиотеки возвращают типы, в которых этот AnsiString используется, но опять же, он используется не в качестве членов, аргументов или типов возвращаемых значений, а для той же генерации исключений (которые опять же определены в заголовочных файлах).
P.S. Или все же причина - Exception?
Правда некотроые члены классов библиотеки возвращают типы, в которых этот AnsiString используется, но опять же, он используется не в качестве членов, аргументов или типов возвращаемых значений, а для той же генерации исключений (которые опять же определены в заголовочных файлах).
Если библиотека экспортирует классы, порожденные от TComponent, использование AnsiString неизбежно - оно происходит неявно. Насчет исключений не уверен, но если библиотека сама не отрабатывает исключения, и они являются штатной ситуацией в ее работе (например, при обращении к файлам или базе данных), это также приводит к неявному использованию AnsiString.
Насколько я понимаю, там говорится примерно следующее: "Если опция включена, в проекте будут использоваться RTL DLL, но тогда их придется включать в дистрибутив. Если отключена - не придется, т.к. компоновщик включит необходимый код в .EXE".
А опции компиляции ДЛЛ и проекта совпадают? Я имею ввиду - Use dinamic RTL отключено в обоих проектах?
А опции компиляции ДЛЛ и проекта совпадают? Я имею ввиду - Use dinamic RTL отключено в обоих проектах?
Да, все совпадает. Но заметил такую странность - когда при компиляции проекта и DLL включаешь "Use dynamic RTL", то все работает нормально. А где взять эти самые DLL RTL (чтобы включить в дистрибутив) я так и не нашел. :-(
Да, все совпадает. Но заметил такую странность - когда при компиляции проекта и DLL включаешь "Use dynamic RTL", то все работает нормально. А где взять эти самые DLL RTL (чтобы включить в дистрибутив) я так и не нашел. :-(
Это библиотеки которые содержат импортируемые из билдера функции. Чтобы посмотреть какие именно нужны - в командной строке набираешь tdamp tvoi.exe > listing и внимательно смотришь. тоже самое нужно делать и для длл. они как правило находятся в бин-директории
... в командной строке набираешь tdamp tvoi.exe > listing и внимательно смотришь.
Набрал "myapp.exe > listing", появилось пустое досовское окно (коим оно и оставалось). После закрытия программы появился (опять же пустой) файл listing. И все. Кстати, что такое "tdamp"?
P.S. Проблема остается.
Кстати, что такое "tdamp"?
TDUMP - Turbo Dump. Программа, существующая с незапамятного времени и показывающая зависимости файлов программ и библиотек. В папке Bin Билдера есть файл tdump.exe. Это и есть искомая программа. У нее два параметра - имя исследуемого файла, после чего можно задать необязательное имя файла результатов. Если файл результатов не задан, они выводятся на экран.
Полученный файл результатов можно посмотреть в любом текстовом редакторе, в Блокноте, или даже в самом Билдере, и понять, от каких статически подключаемых библиотек зависит твоя программа.