Общая библиотека или общий объект — это компьютерный файл , который содержит исполняемый код , предназначенный для использования несколькими компьютерными программами или другими библиотеками во время выполнения , с единственной копией исполняемого кода библиотеки в памяти. Это отличается от статической библиотеки , код которой копируется в исполняемый файл образа программы, когда компоновщик создает этот файл, так что каждая программа имеет свою собственную копию этого кода в памяти.
При запуске программы, использующей общую библиотеку, операционная система загружает общую библиотеку из файла (отличного от исполняемого файла программы) в память во время загрузки или во время выполнения .
Большинство современных операционных систем используют один и тот же формат как для общих библиотек, так и для исполняемых файлов. [NB 1] Это дает два основных преимущества: во-первых, для этого требуется только один загрузчик (создание и обслуживание одного загрузчика считается оправданным любой дополнительной сложностью) [ нужна ссылка ] . Во-вторых, он позволяет использовать исполняемый файл в качестве разделяемой библиотеки (если у него есть таблица символов ). Примеры включают Unix ELF и Mach-O и Windows PE .
В некоторых старых средах, таких как 16-битная Windows или MPE для HP 3000 , в коде общей библиотеки разрешались только данные на основе стека (локальные), или на код общей библиотеки налагались другие существенные ограничения.
Код библиотеки может совместно использоваться в памяти несколькими процессами и на диске. Если используется виртуальная память, процессы будут выполнять одну и ту же физическую страницу ОЗУ, которая отображается в разные адресные пространства процессов. Это имеет преимущества. Например, в системе OpenStep приложения часто имели размер всего несколько сотен килобайт и загружались быстро; большая часть их кода располагалась в библиотеках, которые уже были загружены операционной системой для других целей. [ нужна цитата ]
Программы могут осуществлять совместное использование оперативной памяти, используя позиционно-независимый код , как в Unix , что приводит к сложной, но гибкой архитектуре, или используя общие виртуальные адреса, как в Windows и OS/2 . Эти системы различными способами, такими как предварительное отображение адресного пространства и резервирование слотов для каждой общей библиотеки, гарантируют, что код имеет высокую вероятность совместного использования. Третья альтернатива — одноуровневое хранилище , используемое в IBM System/38 и ее преемниках. Это позволяет использовать код, зависящий от позиции, но не накладывает существенных ограничений на то, где код может быть размещен или как им можно делиться.
В некоторых случаях разные версии общих библиотек могут вызывать проблемы, особенно если библиотеки разных версий имеют одинаковое имя файла, а для каждого из разных приложений, установленных в системе, требуется определенная версия. Такой сценарий известен как DLL-ад , названный в честь DLL-файла Windows и OS/2 . Большинство современных операционных систем после 2001 года имеют методы очистки для устранения таких ситуаций или используют «частные» библиотеки для конкретных приложений. [1]
Динамическое связывание или позднее связывание выполняется во время загрузки программы ( время загрузки ) или выполнения ( время выполнения ), а не при создании исполняемого файла. Динамически подключаемая библиотека ( библиотека динамической компоновки , или DLL, в Windows и OS/2 ; общий образ в OpenVMS ; [2] динамический общий объект, или DSO, в Unix-подобных системах) — это библиотека, предназначенная для динамического связывания. При создании исполняемого файла компоновщик выполняет лишь минимальный объем работы ; он только записывает, какие библиотечные подпрограммы нужны программе, а также индексные имена или номера подпрограмм в библиотеке. Большая часть работы по связыванию выполняется во время загрузки приложения (время загрузки) или во время выполнения (время выполнения). Обычно необходимая программа компоновки, называемая «динамическим компоновщиком» или «линковочным загрузчиком», на самом деле является частью базовой операционной системы . (Однако возможно и не очень сложно написать программу, использующую динамическое связывание и включающую собственный динамический компоновщик, даже для операционной системы, которая сама не поддерживает динамическое связывание.)
Программисты первоначально разработали динамическое связывание в операционной системе Multics , начиная с 1964 года, и MTS ( Michigan Terminal System ), построенной в конце 1960-х годов. [3]
Поскольку общие библиотеки в большинстве систем изменяются нечасто, системы могут вычислить вероятный адрес загрузки для каждой общей библиотеки в системе до того, как она понадобится, и сохранить эту информацию в библиотеках и исполняемых файлах. Если каждая загружаемая общая библиотека прошла этот процесс, то каждая из них будет загружаться по своему заранее определенному адресу, что ускоряет процесс динамического связывания. Эта оптимизация известна как предварительное связывание или предварительное связывание в macOS и Linux соответственно. IBM z/VM использует аналогичный метод, называемый «прерывистыми сохраненными сегментами» (DCSS). [4] Недостатки этого метода включают время, необходимое для предварительного вычисления этих адресов каждый раз при изменении разделяемых библиотек, невозможность использовать рандомизацию структуры адресного пространства и требование достаточного виртуального адресного пространства для использования (проблема, которая будет решена за счет принятие 64-битных архитектур, по крайней мере, на данный момент).
Загрузчики для общих библиотек сильно различаются по функциональности. Некоторые зависят от исполняемого файла, в котором хранятся явные пути к библиотекам. Любое изменение названия библиотеки или структуры файловой системы приведет к сбою этих систем. Чаще всего в исполняемом файле сохраняется только имя библиотеки (а не путь), а операционная система предоставляет метод поиска библиотеки на диске на основе некоторого алгоритма.
Если общая библиотека, от которой зависит исполняемый файл, удалена, перемещена или переименована, или если несовместимая версия библиотеки скопирована в место, находящееся ранее в поиске, исполняемый файл не сможет загрузиться. Это называется адом зависимостей , существующим на многих платформах. (Печально известный) вариант Windows широко известен как DLL hell . Эта проблема не может возникнуть, если каждая версия каждой библиотеки имеет уникальную идентификацию и каждая программа ссылается на библиотеки только по их полным уникальным идентификаторам. Проблемы «DLL-ада» в более ранних версиях Windows возникли из-за использования для разрешения динамических ссылок в программах только имен библиотек, уникальность которых не гарантировалась. (Чтобы избежать «DLL-ада», более поздние версии Windows в основном полагаются на возможности программ устанавливать частные DLL — по сути, частичный отказ от использования общих библиотек — наряду с механизмами, предотвращающими замену общих системных DLL более ранними версиями. )
Microsoft Windows проверяет реестр , чтобы определить подходящее место для загрузки DLL, реализующих COM-объекты , но для других DLL она проверяет каталоги в определенном порядке. Сначала Windows проверяет каталог, в который загружена программа ( частная DLL [1] ); любые каталоги, заданные вызовом SetDllDirectory()функции; каталоги System32, System и Windows; затем текущий рабочий каталог; и, наконец, каталоги, указанные в переменной среды PATH . [5] Приложения, написанные для .NET Framework (с 2002 года), также проверяют глобальный кэш сборок как основное хранилище общих файлов dll, чтобы устранить проблему DLL hell .
OpenStep использовал более гибкую систему, собирая список библиотек из ряда известных мест (аналогично концепции PATH) при первом запуске системы. Перемещение библиотек не вызывает никаких проблем, хотя пользователи несут затраты времени при первом запуске системы.
Большинство Unix-подобных систем имеют «путь поиска», определяющий каталоги файловой системы , в которых следует искать динамические библиотеки. Некоторые системы указывают путь по умолчанию в файле конфигурации , другие жестко запрограммируют его в динамическом загрузчике. Некоторые форматы исполняемых файлов могут указывать дополнительные каталоги для поиска библиотек для конкретной программы. Обычно это можно переопределить с помощью переменной среды , хотя она отключена для программ setuid и setgid, так что пользователь не может заставить такую программу запускать произвольный код с правами root. Разработчикам библиотек рекомендуется размещать свои динамические библиотеки в местах пути поиска по умолчанию. С другой стороны, это может затруднить установку новых библиотек, и эти «известные» места быстро становятся домом для все большего количества файлов библиотек, что усложняет управление.
Динамическая загрузка, подмножество динамического связывания, включает в себя загрузку и выгрузку динамически подключаемой библиотеки во время выполнения по запросу. Такой запрос может быть сделан явно или неявно. Неявные запросы выполняются, когда компилятор или статический компоновщик добавляет ссылки на библиотеки, которые включают пути к файлам или просто имена файлов. [ необходима цитация ] Явные запросы выполняются, когда приложения осуществляют прямые вызовы API операционной системы.
Большинство операционных систем, поддерживающих динамически подключаемые библиотеки, также поддерживают динамическую загрузку таких библиотек через API компоновщика во время выполнения . Например, Microsoft Windows использует функции API и библиотеки Microsoft Dynamic Link Libraries ; Системы на базе POSIX , включая большинство UNIX и UNIX-подобных систем, используют , и . Некоторые системы разработки автоматизируют этот процесс.LoadLibraryLoadLibraryExFreeLibraryGetProcAddressdlopendlclosedlsym
Частные библиотеки DLL — это библиотеки DLL, которые устанавливаются вместе с определенным приложением и используются только этим приложением.