Для системного администратора

В системах Linux имеется два типа исполняемых программ.

1. Исполняемые файлы статической компоновки (Statically linked) содержат все функции библиотек, которые необходимы им для работы. Все библиотечные функции включены в исполняемый файл. Это полные программы, которым не нужны внешние библиотеки для запуска. Одним из преимуществ статически скомпонованных программ является то, что они будут работать без установки зависимостей.
2. Исполняемые файлы динамической компоновки (Dynamically linked) намного меньше по размеру, поскольку они не полные, в том смысле, что для запуска им необходимы функции из внешних совместно используемых (shared) библиотек. Кроме того, что они меньше по размеру, динамическая компоновка позволяет пакету указать от каких библиотек он зависит, без необходимости включения этих библиотек в пакет. Использование динамической компоновки также позволяет многим рабочим программам совместно использовать одну копию библиотеки, вместо того, чтобы занимать память множеством копий одного и того же кода. По этим причинам большинство программ на сегодняшний день используют динамическую компоновку.

Интересным примером типичной системы Linux является команда ln (/bin/ln), создающая связи между файлами или жесткие (hard) связи, или мягкие (soft) (или символические (symbolic)) связи (ссылки). Совместно используемые библиотеки часто используют символические ссылки между универсальным именем и конкретной версией библиотеки. При этом если нарушить некоторые ссылоки на динамические библиотеки, то команда ln (с помощью которой эти ссылки можно быть бы восстановить) тоже становится неработоспособной. Во избежание таких случаев, системы Linux содержат статически скомпонованную версию программы ln под именем sln (/sbin/sln). Листинг 19 иллюстрирует большую разницу в размере между двумя этими программами.

Листинг 19. Размеры sln и ln.

[ian@lyrebird ian]$ ls -l /sbin/sln; ls -l /bin/ln
-rwxr-xr-x 1 root root 457165 Feb 23 2005 /sbin/sln
-rwxr-xr-x 1 root root 22204 Aug 12 2003 /bin/ln


Не принимая во внимание то, что статически скомпонованная программа имеет большой размер. Как мы можем определить является ли программа скомпонованой статически? И если она скомпонована динамически, как нам узнать какие библиотеки ей нужны? Ответ на оба вопроса это команда ldd, отображающая информацию о требуемых библиотеках для исполняемой программы. В Листинге 20 показан вывод команды ldd для исполняемых ln и sln.

Команда ldd

Не принимая во внимание то, что статически скомпонованная программа имеет большой размер. Как мы можем определить является ли программа скомпонованой статически? И если она скомпонована динамически, как нам узнать какие библиотеки ей нужны? Ответ на оба вопроса это команда ldd, отображающая информацию о требуемых библиотеках для исполняемой программы. В Листинге 20 показан вывод команды ldd для исполняемых ln и sln.

Листинг 20. Вывод программы ldd для sln и ln.

[ian@lyrebird ian]$ ldd /sbin/sln /bin/ln
/sbin/sln:
not a dynamic executable
/bin/ln:
libc.so.6 => /lib/tls/libc.so.6 (0x00ebd000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00194000)


Поскольку ldd в действительности предназначен для динамической компоновки она сообщает нам, что sln является статически скомпонованной говоря, что это “not a dynamic executable” (не динамический исполняемый файл), в то время как для ln приводятся имена двух совместно используемых библиотек (libc.so.6 и ld-linux.so.2), которые ей необходимы, а также где их можно найти. Отметим, что .so указывает на то, что обе они являются совместно используемыми объектами (shared objects) или динамическими библиотеками. Для Листинга 21 мы воспользовались командой ls -l, чтобы показать, что это действительно символическая ссылка на конкретные версии библиотек.

Листинг 21. Символические ссылки на библиотеки.

[ian@lyrebird ian]$ ls -l /lib/tls/libc.so.6; ls -l /lib/ld-linux.so.2
lrwxrwxrwx 1 root root 13 May 18 16:24 /lib/tls/libc.so.6 -> libc-2.3.2.so
lrwxrwxrwx 1 root root 11 May 18 16:24 /lib/ld-linux.so.2 -> ld-2.3.2.so

Динамическая загрузка

Исходя из предыдущего, вы можете удивиться, узнав, что ld-linux.so, которая выглядит как библиотека совместного использования, на самом деле по своей природе является исполняемым файлом. Это код, отвечающий за динамическую загрузку. Он читает информацию заголовка исполняемого файла, приведенный в формате Executable and Linking Format (формат ссылок и исполняемых) или (ELF). Из этой информации можно определить какие библиотеки необходимы и какие следует загрузить. Затем он осуществляет динамическое связывание для согласования указателей на адреса в вашем исполняемом файле и загруженных библиотеках, для того, чтобы программа запустилась.

Вы не сможете найти man страницы для ld-linux.so, но вы можете обнаружить их для ld.so, выполнив man ld.so. Листинг 22 иллюстрирует использование опции –list для ld-linux.so, чтобы показать ту же информацию для команды ln, что мы выводили для команды ldd в Листинге 20.

Листинг 22. Использование ld-linux.so для отображения требований для библиотеки.

[ian@lyrebird ian]$ /lib/ld-linux.so.2 --list /bin/ln
libc.so.6 => /lib/tls/libc.so.6 (0x00a83000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00f2c000)

Отметим что шестнадцатиричные адреса для двух листингов отличаются. Скорее всего они будут различны даже если вы запустите ldd дважды.

Настройка динамических библиотек

Итак, как же динамический загрузчик узнает где искать исполняемые файлы? Как и для многого в Linux в /etc имеется конфигурационный файл (configuration file). Фактически два конфигурационных файла: /etc/ld/so/conf и /etc/ld.so.cache. Листинг 23 показывает содержимое /etc/ld.so.conf для двух различных систем. Отметим, что в системе attic4 (под управлением Fedora Core 4), /etc/ld.so.conf указывает, что в подкаталоге ld.so.conf.d должны учитываться все файлы .conf. Реальное содержимое /etc/ld.so.conf для вашей системы может отличаться.

Листинг 23. Содержимое /etc/ld.so.conf.

[ian@lyrebird ian]$ cat /etc/ld.so.conf
/usr/kerberos/lib
/usr/X11R6/lib
/usr/lib/qt-3.1/lib
[
[ian@attic4 ~]$ cat /etc/ld.so.conf
include ld.so.conf.d/*.conf


Необходимо, чтобы загрузка программ проходила быстро, поэтому файл ld.so.conf обрабатывается командой ldconfig для обработки всех библиотек из ld.so.conf.d, а также из надежных каталогов, /lib и /usr/lib. Динамический загрузчик использует файл ld.conf.cache для определения файлов, которые необходимо динамически загрузить и связать. Если вы измените ld.co.conf (или добавите новые включаемые (included) файлы в ld.so.conf.d, то вы должны выполнить команду ldconfig (от имени суперпользователя) чтобы перестроить файл ld.conf.cache.

Обычно вы используете команду ldconfig без параметров для перестройки ld.so.cache. Имеется также несколько параметров, которые вы можете указать для переопределения этого поведения по умолчанию. Как всегда выполните man ldconfig для получения большей информации. Мы проиллюстрировали использование параметра -p для отображения содержимого ld.so.cache в Листинге 24.

Листинг 24. Использование ldconfig для отображения ld.so.cache.

[ian@lyrebird ian]$ /sbin/ldconfig -p | more
768 libs found in cache `/etc/ld.so.cache'
libzvt.so.2 (libc6) => /usr/lib/libzvt.so.2
libz.so.1 (libc6) => /usr/lib/libz.so.1
libz.so (libc6) => /usr/lib/libz.so
libx11globalcomm.so.1 (libc6) => /usr/lib/libx11globalcomm.so.1
libxsltbreakpoint.so.1 (libc6) => /usr/lib/libxsltbreakpoint.so.1
libxslt.so.1 (libc6) => /usr/lib/libxslt.so.1
libxmms.so.1 (libc6) => /usr/lib/libxmms.so.1
libxml2.so.2 (libc6) => /usr/lib/libxml2.so.2
libxml2.so (libc6) => /usr/lib/libxml2.so
libxmltok.so.0 (libc6) => /usr/lib/libxmltok.so.0
libxmlparse.so.0 (libc6) => /usr/lib/libxmlparse.so.0
libxml.so.1 (libc6) => /usr/lib/libxml.so.1
libxerces-c.so.24 (libc6) => /usr/lib/libxerces-c.so.24
...
lib-gnu-activation-20030319.so (libc6) => /usr/lib/lib-gnu-activation-20030319.so
ld-linux.so.2 (ELF) => /lib/ld-linux.so.2

Если вы запускаете старое приложение, которому требуется некая старая версия библиотеки или если вы разрабатываете новую библиотеку или новую версию библиотеки, то вам может понадобиться переопределить путь для поиска по умолчанию, используемый загрузчиком. Это может также понадобиться скриптам, использующим специфичные для продукта библиотеки, устанавливаемые в древо /opt.

Также как вы устанавливаете переменную PATH, вы можете указать путь поиска для исполняемых файлов, вы можете задать переменную LD_LIBRARY_PATH со списком каталогов, разделенных двоеточием, в которых следует искать библиотеки перед тем, как система станет искать их в ld.so.cache. Например, вы можете использовать команду вроде

export LD_LIBRARY_PATH=/usr/lib/oldstuff:/opt/IBM/AgentController/lib

В оставшихся разделах этого учебника мы рассмотрим управление пакетами.

Взято с ibm developerworks