Внутреннее устройство Linux - Уорд Брайан (читать книги полностью .txt) 📗
Однако размеры библиотек постоянно возрастают, равно как и количество используемых библиотек; это делает статические библиотеки неэкономными с точки зрения использования дискового пространства и памяти. Кроме того, если впоследствии обнаружится, что статическая библиотека реализована неадекватно или является незащищенной, то нет никакого способа исправить связанный с ней исполняемый файл, кроме повторной компиляции.
Совместно используемые библиотеки избавляют от таких проблем. Когда вы запускаете команду, связанную с такой библиотекой, система загружает код библиотеки в область памяти процесса только тогда, когда это требуется. Несколько процессов могут совместно использовать один и тот же код библиотеки в памяти. Если вам потребуется немного изменить код библиотеки, то обычно это можно выполнить, не компилируя заново другие команды.
У совместно используемых библиотек есть свои издержки: трудность управления и довольно сложная процедура связывания. Тем не менее можно взять такие библиотеки под контроль, если вы будет знать четыре вещи.
• Как получить список совместно используемых библиотек, необходимых исполняемому файлу.
• Как исполняемый файл отыскивает совместно используемые библиотеки.
• Как связать команду с совместно используемой библиотекой.
• Подводные камни при использовании таких библиотек.
В следующих разделах рассказано о том, как применять и обслуживать совместно используемые библиотеки в вашей системе. Если вам интересно, как устроены эти библиотеки, или вы желаете узнать о компоновщиках в целом, обратитесь к книге Джона Р. Ливайна (John R. Levine) Linkers and Loaders («Компоновщики и загрузчики», Morgan Kaufmann, 1999) или к статье Дэвида М. Бизли (David M. Beazley), Брайана Д. Уарда (Brian D. Ward) и Йена Р. Кука (Ian R. Cooke) The Inside Story on Shared Libraries and Dynamic Loading («Внутренняя история совместно используемых библиотек и динамической загрузки», журнал Computing in Science & Engineering, сентябрь/октябрь 2001), а также к таким онлайн-ресурсам, как Program Library HOWTO (http://dwheeler.com/program-library/). Стоит также прочитать страницу руководства ld.so(8).
Вывод зависимостей совместно используемой библиотеки
Файлы совместно используемой библиотеки обычно размещаются там же, где и статические библиотеки. Двумя стандартными каталогами для библиотек в системе Linux являются /lib и /usr/lib. Каталог /lib не должен содержать статических библиотек.
Имя файла совместно используемой библиотеки содержит суффикс .so (shared object — «совместно используемый объект»), как, например, у файлов libc-2.15.so и libc.so.6. Чтобы увидеть, какие совместно используемые библиотеки применяет команда, запустите команду ldd prog (параметр prog — это имя исполняемого файла). Вот пример для команды оболочки:
$ ldd /bin/bash
linux-gate.so.1 => (0xb7799000)
libtinfo.so.5 => /lib/i386-linux-gnu/libtinfo.so.5 (0xb7765000)
libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7760000)
libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb75b5000)
/lib/ld-linux.so.2 (0xb779a000)
В интересах оптимального быстродействия и гибкости исполняемые файлы обычно не знают о расположении своих совместно используемых библиотек; они знают лишь их названия и, возможно, немного о том, где их искать. Небольшая команда ld.so (динамический компоновщик/загрузчик времени исполнения) отыскивает и загружает совместно используемые библиотеки для команды во время исполнения. В приведенном выше отчете команды ldd имена библиотек показаны слева — именно они известны исполняемому файлу. Правая часть показывает, где команда ld.so ищет данную библиотеку.
Последняя строка приведенного отчета дает актуальное местоположение команды ld.so: ld-linux.so.2.
Как команда ld.so отыскивает совместно используемые библиотеки
Одной распространенной проблемой совместно используемых библиотек является то, что динамический компоновщик не может отыскать библиотеку. Первое местоположение, в котором компоновщику обычно следует искать совместно используемые библиотеки, — это заранее сконфигурированный путь поиска библиотеки времени исполнения (rpath) для исполняемого файла, если такой путь существует. О том, как его определить, вы вскоре узнаете.
Далее динамический компоновщик смотрит в системный кэш /etc/ld.so.cache, чтобы понять, находится ли библиотека в стандартном месте расположения. Это быстрый кэш имен файлов библиотек, найденных в каталогах, которые перечислены в файле конфигурации /etc/ld.so.conf.
примечание
Типичным для файла ld.so.conf, как и для многих файлов конфигурации Linux, которые вы уже видели, является то, что он может включать некоторые файлы из такого каталога, как /etc/ld.so.conf.d.
Каждая строка файла ld.so.conf является каталогом, который вы можете включить в кэш. Перечень каталогов обычно короткий и содержит нечто вроде этого:
/lib/i686-linux-gnu
/usr/lib/i686-linux-gnu
Каталоги стандартных библиотек /lib и /usr/lib являются неявными, это означает, что их не нужно включать в файл /etc/ld.so.conf.
Если изменить файл ld.so.conf или сделать изменения в одном из каталогов совместно используемых библиотек, необходимо перестроить файл /etc/ld.so.cache вручную с помощью следующей команды:
# ldconfig -v
Параметр -v сообщает детальную информацию о библиотеках (которую команда ldconfig добавляет в кэш), а также информацию о любых обнаруженных изменениях.
Есть еще одно место, где команда ld.so ищет совместно используемые библиотеки: переменная окружения LD_LIBRARY_PATH. Вскоре мы поговорим о ней.
Не добавляйте что-либо в файл /etc/ld.so.conf. Вы должны знать, какие совместно используемые библиотеки есть в системном кэше, а если помещать в кэш каждую непонятную маленькую библиотеку, могут возникнуть конфликты и система станет крайне неорганизованной. Когда выполняется компиляция программы, которой необходим нестандартный путь к библиотеке, передайте исполняемому файлу встроенный путь поиска библиотеки времени исполнения. Посмотрим, как это делается.
Связывание программ с совместно используемыми библиотеками
Допустим, у вас есть совместно используемая библиотека с именем libweird.so.1 в каталоге /opt/obscure/lib, с которой вам необходимо связать программу myprog. Выполните это следующим образом:
$ cc -o myprog myprog.o -Wl,-rpath=/opt/obscure/lib -L/opt/obscure/lib -lweird
Параметр -Wl,-rpath сообщает компоновщику о том, чтобы он включил следующий каталог в путь поиска библиотеки времени исполнения для исполняемого файла. Тем не менее, даже если вы используете параметр -Wl,-rpath, флаг -L по-прежнему необходим.
Если у вас уже есть готовый двоичный файл, можно применять команду patchelf, чтобы вставить в него другой путь поиска библиотеки времени исполнения, но обычно лучше делать это во время компиляции.
Проблемы, вызванные совместно используемыми библиотеками
Совместно используемые библиотеки обеспечивают замечательную гибкость, не говоря уже о некоторых действительно превосходных решениях, но в то же время их легко применить неправильно до такой степени, что ваша система превращается в полную кашу. Могут возникнуть три чрезвычайно неприятные ситуации:
• отсутствие библиотек;
• ужасное быстродействие;
• несоответствие библиотек.
Первой причиной всех проблем с совместно используемыми библиотеками является переменная окружения LD_LIBRARY_PATH. Если в этой переменной указать перечень имен каталогов, разделенных с помощью двоеточия, то тогда команда ld.so выполнит поиск в указанных каталогах прежде поиска совместно используемых библиотек где-либо еще. Это легкий способ заставить ваши программы работать, если вы переместили библиотеку и у вас нет исходного кода программы или же вы не можете использовать команду patchelf, а возможно, просто ленитесь заново компилировать исполняемые файлы. К сожалению, вы получаете то, за что платите.
