Мы пытаемся разделить наш монолитный EXE-файл на комбинацию EXE-файла и нескольких пакетов.Пока у нас есть один пакет, который мы пытаемся использовать, и при запуске EXE Codeguard выдает следующую ошибку при запуске:
CG Error
Two different CRTLDLLs are loaded. CG might report false errors
(C:\Windows\system32\CC32100MT.DLL)
(D:\Projects\Foo\Bar.bpl)
OK
Я читаю это как две разные загружаемые библиотеки времени выполнения - одну,правильный (CC32100MT.dll), другой неверный - пакет, который мы пытаемся использовать.
Продолжение запуска программы показывает странные ошибки, особенно приведение между классами или передача указателя накласс в качестве параметра в методе, который пересекает границу EXE / DLL.Однако сам Codeguard вообще не показывает никаких других ошибок. Редактировать: Теперь это решено и не связано.Кажется, что программа работает правильно, но предупреждение Codeguard все еще вызывает беспокойство.
Как мы можем решить эту проблему?
Некоторые подробности
Мы рассмотрели столько жевещи, о которых мы (разработчик, работающий над этим, и я) можем думать вместе:
Каждый проект создается с использованием пакетов времени выполнения.Узел EXE перечисляет Bar в своем списке пакетов.
Каждый проект настроен на компиляцию с динамическим RTL.Однако изменение этого параметра не решает проблему.
Пакет связан с EXE-файлом через его файл BPI, но подключение через LIB также не имеет значения.
EXE и BPL компилируются с одинаковыми настройками проекта, где для обоих типов проекта существуют одинаковые параметры.В любом случае, мы думаем:)
В системе есть только одна копия BPL и BPI: она определенно связана с нужной.
Изучение EXE и BPL с Depends и TDump показывает, что они оба используют C:\Windows\system32\CC32100MT.DLL.Они должны оба использовать один RTL.
Создание нового проекта (простое приложение VCL-форм) и связывание с BPL (через его BPI) работает нормально,Что-то в процессе добавления всех файлов и LIB, которые делают наш EXE-файл, содержит код, необходимый для его изменения, но мы не смогли выяснить, что.
LIBsвсе они либо соответствуют используемым нами DLL-библиотекам (плоский интерфейс C, как правило, выглядят так, как будто они были созданы с помощью MSVC), либо представляют собой простые проекты с большим количеством связанных файлов, скомпилированных в lib для ссылки на EXE - они примерно соответствуютКстати, разделы программы, которые мы хотим разделить на BPL.Похоже, что нет вариантов проекта для проектов LIB, которые могли бы повлиять на RTL-соединение, если только мы не пропустили их.
Я исчерпывающе искал через Depends и посмотрел всеRTL и CC32 * .dll файлы EXE и все ссылки на DLL.Все идентичны: rtl140.bpl и CC32100MT.DLL.Полные пути показывают, что они тоже являются одинаковыми файлами.Все должно быть с использованием одной и той же библиотеки времени выполнения.
Редактировать: Окончательный EXE-файл сложен, состоит из нескольких библиотек, нескольких библиотек DLL и т. Д. Все эти, при сборке с C ++ Builder, с текущей версией.Возможно ли, что в одной из этих библиотек или библиотек есть что-то, что может вызвать проблемы?Я не знаю достаточно о том, как RTL связан, чтобы быть уверенным в том, где искать ... мое (наивное?) Предположение, что компоновщик обычно связывает в одном наборе функций RTL, но это, конечно, некажется, что происходит ... и я не знаю, как все меняется при использовании пакетов.Возможно ли, что эта ошибка существовала всегда, и Codeguard не помечал ее раньше, потому что мы не использовали что-то динамическое, такое как пакет?
Возможно, другой вопрос: почему пакет в любом случае имеет свой собственный RTL, иличто бы сделать это считать «RTL DLL» для Codeguard?
Мы в тупике. Абсолютно в тупик. У нас были другие проблемы с использованием BPL (они кажутся удивительно сложными, особенно с использованием C ++), но нам удалось решить их все. На этот раз нам не повезло, и мы были бы очень благодарны за любые идеи:)
Мы используем C ++ Builder 2010 (фактически, как часть RAD Studio, но с небольшим количеством кода Delphi, кроме компонентов).
Редактировать: Началось вознаграждение. Я бы очень хотел решить это!
Редактировать 2: Благодарю Дэвида Дина за помощь (помечен как ответ ниже.) По электронной почте он указал, что этот вопрос был воспроизведен кем-то еще в простом тестовом примере. , и вошел в систему Embarcadero QC как отчет 86335 . В настоящее время исправления не существует, но предупреждение не указывает на подлинную проблему (т. Е. , вероятно, - ложная ошибка, и, хотя при запуске программы жаль, что приходится проходить мимо диалогового окна, надеюсь, что Ничего страшного в этой ошибке нет.)