Внутреннее устройство Linux

/usr/lib/i686-linux-gnu

Каталоги стандартных библиотек /lib и /usr/lib являются неявными, это означает, что их не нужно включать в файл /etc/ld.so.conf.

Если изменить файл ld.so.conf или сделать изменения в одном из каталогов совместно используемых библиотек, необходимо перестроить файл /etc/ld.so.ca­che вручную с помощью следующей команды:

# 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, а возможно, просто ленитесь заново компилировать исполняемые файлы. К сожалению, вы получаете то, за что платите.

Никогда не определяйте переменную LD_LIBRARY_PATH в файлах запуска оболочки или при компиляции программ. Когда динамический компоновщик встречает эту переменную, ему зачастую приходится просматривать содержимое каждого указанного каталога большее число раз, чем вы могли себе представить. Это сильно сказывается на быстродействии, но, что более важно, могут возникнуть конфликты и несоответствия библиотек, поскольку компоновщик времени исполнения просматривает эти каталоги для каждой программы.

Если вы должны использовать переменную LD_LIBRARY_PATH, чтобы запустить какую-либо программу, для которой у вас нет исходного кода (или приложение, которое вы предпочли бы не компилировать, вроде Mozilla или каких-либо других), применяйте сценарий обертки. Допустим, исполняемому файлу /opt/crummy/bin/crummy.bin необходимы совместно используемые библиотеки из каталога /opt/crummy/lib. Напишите сценарий обертки с именем crummy следующим образом:

#!/bin/sh

LD_LIBRARY_PATH=/opt/crummy/lib

export LD_LIBRARY_PATH

exec /opt/crummy/bin/crummy.bin $@

Если избегать переменной LD_LIBRARY_PATH, то можно предотвратить большинство проблем с совместно используемыми библиотеками. Иногда возникает еще одна существенная проблема для разработчиков: интерфейс прикладного программирования (API) для какой-либо библиотеки может немного измениться при переходе от одной младшей версии к другой, это нарушит работу установленных программ. Лучшие решения проблемы являются профилактическими: либо пользуйтесь последовательной методологией, чтобы установить совместно использу­емые библиотеки с помощью команды -Wl,-rpath для создания ссылки на путь времени исполнения, либо просто применяйте статические версии непонятных библиотек.

15.2. Утилита make