# gcc — g — shared — Wl, — soname,libdemo.so.1 — o libdemo.so.1.0.2 \
mod1.o mod2.o mod3.o
# mv libdemo.so.1.0.2 /usr/lib
# ldconfig — v | grep libdemo
libdemo.so.1 — > libdemo.so.1.0.2 (changed)
Если исходное компоновочное имя было установлено правильно (так, чтобы оно указывало на soname), не пришлось бы его менять.
Программа, запущенная ранее, продолжит использовать предыдущую минорную версию разделяемой библиотеки. Новая версия станет доступной только после перезапуска.
Если вслед за этим мы заходим создать новую мажорную версию (2.0.0), придется выполнить следующие шаги:
# gcc — g — c — fPIC — Wall mod1.c mod2.c mod3.c
# gcc — g — shared — Wl, — soname,libdemo.so.2 — o libdemo.so.2.0.0 \
mod1.o mod2.o mod3.o
# mv libdemo.so.2.0.0 /usr/lib
# ldconfig — v | grep libdemo
libdemo.so.1 — > libdemo.so.1.0.2
libdemo.so.2 — > libdemo.so.2.0.0 (changed)
# cd /usr/lib
# ln — sf libdemo.so.2 libdemo.so
Как можно видеть выше, ldconfig автоматически создает символьную ссылку на имя soname для новой мажорной версии. Но, как показывает последняя команда, обновлять символьную ссылку на компоновочное имя приходится вручную.
Мы уже познакомились с двумя способами оповещения динамического компоновщика о местоположении разделяемой библиотеки: используя переменную среды LD_LIBRARY_PATH и путем установки библиотеки в один из стандартных библиотечных каталогов (/lib, /usr/lib или в один из перечисленных в файле /etc/ld.so.conf).
Но есть и третий путь: на этапе статического редактирования в исполняемый файл можно вставить список каталогов, в которых во время выполнения следует искать разделяемые библиотеки. Данный путь бывает полезен в ситуациях, когда библиотеки находятся в заранее определенных, но нестандартных местах, о которых не знает динамический компоновщик. Для этого при создании исполняемого файла можно воспользоваться параметром компоновщика — rpath:
$ gcc — g — Wall — Wl, — rpath,/home/mtk/pdir — o prog prog.c libdemo.so
Команда, приведенная выше, копирует строку /home/mtk/pdir в список путей времени выполнения (rpath) исполняемого файла prog, чтобы во время запуска этой программы динамический компоновщик выполнял поиск разделяемых библиотек и по заданному каталогу.
При необходимости параметр — rpath можно указать несколько раз; все каталоги будут объединены в упорядоченный список и помещены в исполняемый файл. То же самое можно сделать, задействуя один параметр — rpath, перечисляя пути через двоеточие. Во время выполнения динамический компоновщик будет искать по этим каталогам в порядке их указания с помощью параметра (-ов) — rpath.
Вместо параметра — rpath можно использовать переменную среды LD_RUN_PATH. Ей можно присвоить строку со списком путей, разделенных двоеточиями, который будет применяться в качестве rpath на этапе сборки исполняемого файла. Переменная LD_RUN_PATH учитывается только в том случае, если во время компоновки не было указано параметра — rpath.
Параметр компоновщика — rpath можно также применять при сборке разделяемой библиотеки. Допустим, у нас есть библиотека libx1.so, зависящая от другой, libx2.so (рис. 41.4). Представим также, что эти библиотеки находятся в нестандартных каталогах соответственно d1 и d2. Теперь пройдемся по этапам, необходимым для их сборки и создания программы, которая их использует.
Рис. 41.4.
Для начала создадим файл libx2.so в каталоге pdir/d2 (чтобы не усложнять пример, обойдемся без нумерации версий и задания имен soname вручную).
$ cd /home/mtk/pdir/d2
$ gcc — g — c — fPIC — Wall modx2.c
$ gcc — g — shared — o libx2.so modx2.o
Теперь создадим библиотеку libx1.so в каталоге pdir/d1. Поскольку libx1.so зависит от файла libx2.so, находящегося в нестандартном каталоге, путь к данному файлу будет указан с помощью параметра компоновщика — rpath. Это значение может отличаться от каталога, который применяется во время компоновки библиотеки (и задается с использованием параметра — L), но в данном случае оба пути совпадают.
$ cd /home/mtk/pdir/d1
$ gcc — g — c — Wall — fPIC modx1.c