Linux API. Исчерпывающее руководство

Мы могли бы выборочно переопределить функцию x1(), создав еще одну разделяемую библиотеку, libalt.so, с другой версией x1() внутри. Если предварительно загрузить эту библиотеку во время запуска программы, то получится следующий результат:

$ LD_PRELOAD=libalt.so./prog

Called mod1-x1 ALT

Called mod2-x2 DEMO

Как видите, здесь вызывается версия x1(), определенная в библиотеке libalt.so, однако вызов x2(), определение которого не содержится в libalt.so, приводит к запуску функции x2() из библиотеки libdemo.so.

Переменная среды LD_PRELOAD управляет процедурой предварительной загрузки для каждого отдельного процесса. Чтобы сделать то же самое на уровне системы, можно воспользоваться файлом /etc/ld.so.preload, который содержит список библиотек, разделенных пробельными символами (библиотеки, указанные в переменной LD_PRELOAD, загружаются раньше перечисленных в /etc/ld.so.preload).

Из соображений безопасности программы, устанавливающие пользовательские и групповые идентификаторы, игнорируют переменную LD_PRELOAD.

42.6. Мониторинг работы динамического компоновщика: LD_DEBUG

Иногда бывает полезно проследить за работой динамического компоновщика, чтобы, например, понять, где именно он ищет библиотеки. Для этого можно использовать переменную среды LD_DEBUG. Присвоив ей одно (или несколько) из стандартных ключевых слов, мы получим различные сведения, касающиеся того, как динамический компоновщик проводит поиск.

Если присвоить переменной LD_DEBUG значение help, то динамический компоновщик выведет справочную информацию, а сама команда не будет выполнена:

$ LD_DEBUG=help date

Valid options for the LD_DEBUG environment variable are:

Libs display library search paths

reloc display relocation processing

files display progress for input file

symbols display symbol table processing

bindings display information about symbol binding

versions display version dependencies

all all previous options combined

statistics display relocation statistics

unused determine unused DSOs

help display this help message and exit

В следующем примере представлен несколько сокращенный вариант вывода, который получается при запросе сведений о процессе поиска библиотек:

$ LD_DEBUG=libs date

10687: find library=librt.so.1 [0]; searching

10687: search cache=/etc/ld.so.cache

10687: trying file=/lib/librt.so.1

10687: find library=libc.so.6 [0]; searching

10687: search cache=/etc/ld.so.cache

10687: trying file=/lib/libc.so.6

10687: find library=libpthread.so.0 [0]; searching

10687: search cache=/etc/ld.so.cache

10687: trying file=/lib/libpthread.so.0

10687: calling init: /lib/libpthread.so.0

10687: calling init: /lib/libc.so.6

10687: calling init: /lib/librt.so.1

10687: initialize program: date

10687: transferring control: date

Tue Dec 28 17:26:56 CEST 2010

10687: calling fini: date [0]

10687: calling fini: /lib/librt.so.1 [0]

10687: calling fini: /lib/libpthread.so.0 [0]

10687: calling fini: /lib/libc.so.6 [0]

Значение 10687, выводимое в начале каждой строчки, — идентификатор процесса, который мы отслеживаем. Оно помогает при мониторинге нескольких процессов (например, родительского и дочернего).

Результат по умолчанию записывается в стандартный вывод ошибок, но можно перенаправить его любое другое место, назначив переменной среды LD_DEBUG_OUTPUT подходящий путь.

При желании переменной LD_DEBUG можно присвоить сразу несколько параметров, разделяя их запятыми (но без пробелов). Особенно подробным является вывод параметра symbols (который отслеживает поиск символов динамическим компоновщиком).

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

Из соображений безопасности переменная LD_DEBUG игнорируется программами, устанавливающими пользовательские и групповые идентификаторы (начиная с glibc 2.2.5).

42.7. Резюме

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

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

Мы также показали, как версионные сценарии можно применять для экспорта из библиотеки нескольких вариантов одного и того же символа, которые будут использоваться разными программами, скомпонованными с этой библиотекой. (Каждое приложение задействует определение, являющееся текущим на момент его статической компоновки.) Такой подход — альтернатива традиционному версионированию библиотек с помощью номеров минорных и мажорных версий в реальном имени библиотеки.