Связывание файлов Windows DLL из статических библиотек с использованием CMake без ручной обработки неразрешенных имен символов - PullRequest
Новая
       73

Связывание файлов Windows DLL из статических библиотек с использованием CMake без ручной обработки неразрешенных имен символов

26 голосов
/ 28 февраля 2011

Ситуация

Я использую Visual Studio 2008 SP1 (Professional Edition, как для 32-разрядных, так и для 64-разрядных сборок).Я ищу обходной путь к тому, что я считаю очень бесполезным " ограничение " в Visual Studio.

Я нахожу довольно удивительным, что компоновщик и компилятор Visual Studio не делает этого прямо во время создания DLL-файла, чтобы автоматически сканировать все указанные статические библиотеки на предмет всех экспортируемых символов таким же образом, как указано в Создание библиотеки импорта и файла экспорта и комментария StackOverflow .Я подтвердил, что недостаточно просто применять атрибуты __declspec(dllexport) и __declspec(dllimport) к объявлениям классов, функций и данных в файлах, которые составляют статические библиотеки.

Компоновщик не сканирует все статические библиотеки на предмет экспортированных символов и поэтому не вытягивает их в файл DLL (на символы нужно ссылаться в файлах .obj в командной строке DLL-ссылки илидругими способами я покажу ниже).Без явных ссылок на каждый экспортируемый символ файл DLL все еще может быть создан, но связанный с ним файл библиотеки импорта не создан.

Из того, что я могу собрать, Microsoft рекомендует использовать LIB.EXE для создания файла DEF , но, к сожалению, на странице LIB.EXE применяется ограничение:

Обратите внимание, что при создании библиотеки импорта впредварительный шаг, перед созданием .dll вы должны передать тот же набор объектных файлов при создании .dll, что и при создании библиотеки импорта.

Это прискорбное ограничениечто я также использую CMake в моей новой среде сборки.CMake скрывает детали того, что фактически передается компоновщику (и я считаю, что это хорошо в 99% случаев), но в этом случае мне нужно получить доступ к этой информации во время выполнения CMake, а невпоследствии с использованием созданных вручную сценариев или других хрупких skulduggery .

Вопросы:

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

Мои вопросы:

  1. КакЯ получаю набор объектных файлов и статических библиотек, используемых в окончательной командной строке DLL-библиотеки, используя только синтаксис CMake?

  2. Должен ли порядок файлов, перечисленных в строке LIB.EXE (тот, который использовался для создания файла DEF ), точно соответствоватьпорядок, используемый на линии связи DLL?

  3. Могут ли я столкнуться с другими трудностями при использовании подхода LIB.EXE для создания DEF file?

  4. Есть ли лучший способ сделать это, не требующий вызова отдельной утилиты, такой как LIB.EXE, за до вызова финалассылка на сайт?Я обеспокоен добавленными издержками сборки помимо самой ссылки для LIB.EXE для повторного сканирования всех статических библиотек снова , даже если он просто записал их в отдельных исполнениях.

Неотвечающие:

Ниже приведены решения, которые я не могу рассмотреть прямо сейчас:

  1. Ручное указание ссылочных символов в любом местекроме как в исходных .h или .cpp файлах, так как это будет нарушаться каждый раз, когда разработчик забывает обновить файл, в котором перечислено (возможно, искаженное) имя символа.И это порвется с не дружественными к пользователю ошибками компоновщика о неразрешенных символах, которые для разработчиков будут дорогостоящими для отладки.Этот не ответ включает в себя следующие подходы:

    1. Явно добавленные .obj файлы в командную строку DLL-ссылки,(варианты этого включают добавление "поддельных" .obj файлов, которые имеют фиктивные ссылки на иные не связанные, но экспортированные символы (и обратите внимание, что это то, что моя старая среда сборки делает сегодня, и воняет)) и,

    2. Ручная работа DEF файлов для включения в него не связанных, но экспортируемые символы и

    3. Параметры командной строки компоновщика, которые конкретно ссылаются на не связанные, но экспортированные символы символы.

  2. Полностью прекратить использование статических библиотек. Я не могу сделать это в краткосрочные, так как это слишком много структурных изменений по сравнению со старым создать среду, от которой я ухожу. Вполне вероятно, я буду Пройдите по этому маршруту в будущем, когда-нибудь все остатки старой постройки окружение находится в «мусорном ведре», но это не мое внимание здесь.

Справочный материал:

1 Ответ

2 голосов
/ 20 августа 2011

Я только отвечаю, чтобы вы поняли, что ваше чувство не использовать статические библиотеки правильное.

DLRdave сказал, что это уже в комментариях, ваша система сборки используется LIB-файлами. LIB-файл очень похож на настоящую библиотеку, вы просто получаете то, о чем просите, а не все в библиотеке.

Если в наборе инструментов Visual Studio 2008 есть пробел, значит, он не поддерживает частичное связывание. Входные данные в частичную ссылку представляют собой набор OBJ-файлов, а выходные данные представляют собой один OBJ-файл, который содержит весь код и данные из входных OBJ-файлов.

Различие между архивом / библиотекой и частичной ссылкой описано для g ++ в ответе на этот вопрос: g ++ частичное связывание вместо архивов? , где компоновщик GNU ( ld ) поддерживает частичное связывание.

Что касается возможного краткосрочного смягчения - лично я бы попытался использовать сценарии для динамической сборки файла DEF во время сборки, используя LIB /List или DUMPBIN /ARCHIVEMEMBERS для получения файлов obj и LIB /DEF для генерации DEF файл из этого списка. Или, как я полагаю, используется _declspec(dllexport), вы могли бы также использовать DUMPBIN /DIRECTIVES, искать /EXPORT и создавать файл DEF самостоятельно.

...