Почему компоновщик C++ требует файлов библиотеки во время сборки, даже при том, что я динамично связываюсь?
У меня есть исполняемый файл C++, и я динамично связываюсь против нескольких библиотек (Повышение, Xerces-c и пользовательский освобождает).
Я понимаю, почему я потребовал бы .lib/.a файлов, если я принимаю решение статически связаться против этих библиотек (релевантный ТАК вопрос здесь). Однако, почему я должен обеспечить соответствующие .lib/.so файлы библиотеки при соединении моего исполняемого файла, если я динамично связываюсь против этих внешних библиотек?
6 ответов
Компилятор не знает о динамической компоновке, он просто знает, что функция существует через свой прототип. Компоновщику нужны файлы библиотеки для разрешения символа. Библиотека для DLL содержит дополнительную информацию, например, в какой DLL находятся функции и как они экспортируются (по имени, порядковому номеру и т. Д.). Файлы библиотеки для DLL содержат гораздо меньше информации, чем файлы библиотеки, содержащие полный объектный код - libcmmt .lib в моей системе составляет 19,2 МБ, но msvcrt.lib составляет «всего» 2,6 МБ.
Обратите внимание, что этой модели компиляции / компоновки на данный момент почти 40 лет, и она предшествует динамической компоновке на большинстве платформ. Если бы он был разработан сегодня, динамическое связывание было бы первоклассным гражданином (например, в .NET каждая сборка имеет обширные метаданные, точно описывающие то, что она экспортирует, поэтому вам не нужны отдельные заголовки и библиотеки).
Во-первых, компоновщик вставляет версии библиотек, которые существуют во время компоновки, чтобы у вас была некоторая вероятность того, что ваша программа будет работать, если версии библиотек будут обновлены. В системе может существовать несколько версий разделяемых библиотек.
Возможно, это динамическое связывание выполняется через библиотеки импорта (функция перед определением имеет __declspec (dllimport)).
Если это так, то компилятор ожидает, что там объявлена функция __imp_symbol, и эта функция отвечает за перенаправление вызова в нужную динамически загружаемую библиотеку.
Эти функции генерируются при связывании символов с ключевым словом __declspec (dllimport)
Вот очень УПРОЩЕННОЕ описание, которое может помочь. Статическая компоновка помещает весь код, необходимый для запуска вашей программы, в исполняемый файл, чтобы все было найдено. Динамическое связывание означает, что часть необходимого кода не помещается в исполняемый файл и будет найдена во время выполнения. Где мне это найти? Есть ли функция x ()? Как мне вызвать функцию x ()? Это то, что библиотека сообщает компоновщику при динамической компоновке.
Raymond Chen написал пару записей в блоге об этом конкретном для Windows. Начните с классической модели для связывания , а затем последующие работы с Почему у нас в любом случае у нас есть библиотеки импорта? .
Для суммирования история определила компилятор в качестве компонента, который знает информацию о детальной информации, в то время как линкер знает только о именах символов. Таким образом, линкер заканчивается создание .dll без информации, и, следовательно, программы, которые хотят связать с ним, нужны какие-то метаданные, чтобы рассказать о том, как функции экспортируются и какие типы параметров они берут и возвращают.
Причина .dlls У вас нет вся информация, необходимая с ними, - это историческая, а не техническое ограничение.
Синкер имеет место, чтобы проверить, что все Ваши неопределенные символы учитываются либо со статическим содержанием или динамическим содержанием.
По умолчанию, то он настаивает на том, что все ваши символы присутствуют.
Тем не менее, это просто по умолчанию. Смотрите -z, и --ally-Shlib-undefined, а друзья.