Общая библиотека

Общая библиотека или общий объект — это компьютерный файл , содержащий исполняемый код , предназначенный для использования несколькими компьютерными программами или другими библиотеками во время выполнения .

При запуске программы, настроенной на использование общей библиотеки, операционная система загружает общую библиотеку из файла (отличного от исполняемого файла программы) в память во время загрузки или во время выполнения . В качестве альтернативы программа может быть монолитной - построенной так, чтобы включать исполняемый код библиотеки в свой исполняемый файл, но код библиотеки, встроенный в исполняемый файл программы, не может использоваться другими программами.

Общие библиотеки могут быть статически связаны во время компиляции. Это означает, что ссылки на библиотеку разрешаются, и библиотеке выделяется память при создании исполняемого файла. ^{[ нужна ссылка ]} Но часто связывание общих библиотек откладывается до их загрузки. ^{[ сомнительно – обсудить ]}

Большинство современных операционных систем используют один и тот же формат как для общих библиотек, так и для исполняемых файлов. ^{[Примечание 1]} Это дает два основных преимущества: во-первых, для этого требуется только один загрузчик (создание и обслуживание одного загрузчика считается оправданным при любых дополнительных сложностях). ^{[ нужна ссылка ]}. Во-вторых, он позволяет использовать исполняемый файл в качестве разделяемой библиотеки (если у него есть таблица символов ). Примеры форматов файлов, используемых как для общих библиотек, так и для исполняемых файлов, включают ELF , Mach-O и PE .

В некоторых старых средах, таких как 16-битная Windows или MPE для HP 3000 , в коде общей библиотеки разрешались только данные на основе стека (локальные), или на код общей библиотеки налагались другие существенные ограничения.

Совместное использование памяти [ править ]

Код библиотеки может совместно использоваться в памяти несколькими процессами и на диске. Если используется виртуальная память, процессы будут выполнять одну и ту же физическую страницу ОЗУ, которая отображается в разные адресные пространства процессов. Это имеет преимущества. Например, в системе OpenStep приложения часто имели размер всего несколько сотен килобайт и загружались быстро; большая часть их кода располагалась в библиотеках, которые уже были загружены операционной системой для других целей. ^{[ нужна ссылка ]}

Программы могут осуществлять совместное использование оперативной памяти, используя позиционно-независимый код , как в Unix , что приводит к сложной, но гибкой архитектуре, или используя общие виртуальные адреса, как в Windows и OS/2 . Эти системы различными способами, такими как предварительное отображение адресного пространства и резервирование слотов для каждой общей библиотеки, гарантируют, что код имеет высокую вероятность совместного использования. Третья альтернатива — одноуровневое хранилище , используемое в IBM System/38 и ее преемниках. Это позволяет использовать код, зависящий от позиции, но не накладывает существенных ограничений на то, где код может быть размещен или как им можно делиться.

В некоторых случаях разные версии общих библиотек могут вызывать проблемы, особенно если библиотеки разных версий имеют одно и то же имя файла, а каждому из разных приложений, установленных в системе, требуется определенная версия. Такой сценарий известен как DLL-ад Windows и OS/2 , названный в честь DLL-файла . Большинство современных операционных систем после 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 [ править ]

Microsoft Windows проверяет реестр , чтобы определить подходящее место для загрузки DLL, реализующих COM-объекты , но для других DLL она проверяет каталоги в определенном порядке. Сначала Windows проверяет каталог, в который загружена программа ( частная DLL ^[1]); любые каталоги, заданные вызовом SetDllDirectory() функция; каталоги System32, System и Windows; затем текущий рабочий каталог; и, наконец, каталоги, указанные в переменной среды PATH . ^[5] Приложения, написанные для .NET Framework (начиная с 2002 года), также проверяют глобальный кэш сборок как основное хранилище общих файлов DLL, чтобы устранить проблему DLL hell .

ОпенСтеп [ править ]

OpenStep использовал более гибкую систему, собирая список библиотек из ряда известных мест (аналогично концепции PATH) при первом запуске системы. Перемещение библиотек не вызывает никаких проблем, хотя пользователи несут затраты времени при первом запуске системы.

Unix-подобные системы [ править ]

Большинство Unix-подобных систем имеют «путь поиска», определяющий каталоги файловой системы , в которых следует искать динамические библиотеки. Некоторые системы указывают путь по умолчанию в файле конфигурации , другие жестко запрограммировали его в динамическом загрузчике. Некоторые форматы исполняемых файлов могут указывать дополнительные каталоги для поиска библиотек для конкретной программы. Обычно это можно переопределить с помощью переменной среды , хотя она отключена для программ setuid и setgid, так что пользователь не может заставить такую программу запускать произвольный код с правами root. Разработчикам библиотек рекомендуется размещать свои динамические библиотеки в местах пути поиска по умолчанию. С другой стороны, это может затруднить установку новых библиотек, и эти «известные» места быстро становятся домом для все большего количества файлов библиотек, что усложняет управление.

Динамическая загрузка [ править ]

Динамическая загрузка, подмножество динамического связывания, включает в себя загрузку и выгрузку динамически подключаемой библиотеки во время выполнения по запросу. Такой запрос может быть сделан явно или неявно. Неявные запросы выполняются, когда компилятор или статический компоновщик добавляет ссылки на библиотеки, которые включают пути к файлам или просто имена файлов. ^{[ нужна ссылка ]} Явные запросы выполняются, когда приложения осуществляют прямые вызовы API операционной системы.

Большинство операционных систем, поддерживающих динамически подключаемые библиотеки, также поддерживают динамическую загрузку таких библиотек через во время выполнения компоновщика API . Например, Microsoft Windows использует функции API LoadLibrary, LoadLibraryEx, FreeLibrary и GetProcAddress с библиотеками динамических ссылок Microsoft ; POSIX -системы, включая большинство UNIX и UNIX-подобных систем, используют dlopen, dlclose и dlsym. Некоторые системы разработки автоматизируют этот процесс.

Примечания [ править ]

^ Некоторые старые системы, например, Burroughs MCP , Multics , также имеют единый формат.

Дальнейшее чтение [ править ]

Как писать общие библиотеки Ульриха Дреппера (с большим количеством справочной информации)

Ссылки [ править ]

^ Jump up to: Перейти обратно: ^а ^б Андерсон, Рик (11 января 2000 г.). «Конец ада DLL» . microsoft.com. Архивировано из оригинала 5 июня 2001 г. Проверено 15 января 2012 г. Частные библиотеки DLL — это библиотеки DLL, которые устанавливаются вместе с определенным приложением и используются только этим приложением.
^ «Руководство по утилите VSI OpenVMS Linker» (PDF) . ВСИ. Август 2019 года . Проверено 31 января 2021 г.
^ «История МТС». Дайджест информационных технологий . 5 (5).
^ Корпорация IBM (2011). Планирование и администрирование сохраненных сегментов (PDF) . Проверено 29 января 2022 г.
^ «Порядок поиска в библиотеке Dynamic-Link» . Сетевая библиотека разработчиков Microsoft . Майкрософт. 6 марта 2012 г. Архивировано из оригинала 9 мая 2012 года . Проверено 20 мая 2012 г.

[1] Некоторые старые системы, например, Burroughs MCP , Multics , также имеют единый формат.

[endofdllhell-2] Jump up to: Перейти обратно: ^а ^б Андерсон, Рик (11 января 2000 г.). «Конец ада DLL» . microsoft.com. Архивировано из оригинала 5 июня 2001 г. Проверено 15 января 2012 г. Частные библиотеки DLL — это библиотеки DLL, которые устанавливаются вместе с определенным приложением и используются только этим приложением.

[3] «Руководство по утилите VSI OpenVMS Linker» (PDF) . ВСИ. Август 2019 года . Проверено 31 января 2021 г.

[4] «История МТС». Дайджест информационных технологий . 5 (5).

[5] Корпорация IBM (2011). Планирование и администрирование сохраненных сегментов (PDF) . Проверено 29 января 2022 г.

[6] «Порядок поиска в библиотеке Dynamic-Link» . Сетевая библиотека разработчиков Microsoft . Майкрософт. 6 марта 2012 г. Архивировано из оригинала 9 мая 2012 года . Проверено 20 мая 2012 г.

[Примечание 1]

[1]

[2]

[3]

[4]

[5]