Мы могли бы выборочно переопределить функцию 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.
Иногда бывает полезно проследить за работой динамического компоновщика, чтобы, например, понять, где именно он ищет библиотеки. Для этого можно использовать переменную среды 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).
Динамический компоновщик предоставляет программный интерфейс dlopen, позволяющий программам самостоятельно загружать дополнительные разделяемые библиотеки во время выполнения. Это позволяет реализовать подключаемые модули.
Важным аспектом проектирования разделяемых библиотек является управление видимостью символов, поскольку это делает возможным экспорт только тех функций и переменных, которые должны быть доступны программам, скомпонованным с нашей библиотекой. Мы рассмотрели различные методики, помогающие управлять видимостью символов, включая использование версионных сценариев, позволяющих контролировать все нюансы данного процесса.
Мы также показали, как версионные сценарии можно применять для экспорта из библиотеки нескольких вариантов одного и того же символа, которые будут использоваться разными программами, скомпонованными с этой библиотекой. (Каждое приложение задействует определение, являющееся текущим на момент его статической компоновки.) Такой подход — альтернатива традиционному версионированию библиотек с помощью номеров минорных и мажорных версий в реальном имени библиотеки.