Как приложения обрабатывают разные версии разделяемых библиотек во время выполнения?

Я не знаю, как работают общие библиотеки на Linux. Я пытаюсь понять, как приложения разрешают различные версии одной и той же разделяемой библиотеки во время выполнения в Linux.

Насколько я понимаю, в общей библиотеке есть три "имени", например

libmy.so.1.2 (реальное имя, то есть фактический файл obj)
libmy.so.1 (SONAME, который встроен в фактический файл obj)
libmy.so(имя компоновщика, предоставленное компоновщику во время соединения и встроенное в исполняемый файл)

Когда вы устанавливаете библиотеку через LDCONFIG, она создаст следующие символические ссылки

(2) = > (1)
(3) = > (2)

Теперь скажем, что я скомпилирую другую версию той же библиотеки со следующим именем, libmy.so.2.0. SONAME по рекомендациям будет libmy.so.2.0

Во время ссылки на приложение укажите, что такое имя компоновщика, которое я бы предоставил с флагом -l. Следуя рекомендациям, которые я прочитал (http://www.dwheeler.com/program-library/Program-Library-HOWTO/x36.htm l), не было бы это libmy.so, и если да, то как обе версии выделить файл obj?

Ответ 1

Версии общих объектов работают следующим образом:

Когда вы создаете общий объект, вы даете ему как настоящее имя, так и soname. Они используются для установки общего объекта (который создает как объект, так и ссылку на него).

Таким образом, вы можете столкнуться с ситуацией:

pax> ls -al xyz*
-rw-r--r--  1 pax paxgroup    12345 Nov 18  2009 xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so.1 -> xyz.so.1.5
lrwxrwxrwx  1 pax paxgroup        0 Nov 18  2009 xyz.so -> xyz.so.1

с xyz.so.1.5, имеющим soname of xyz.so.1.

Когда компоновщик ссылается в xyz.so, он следует за ссылками вплоть до xyz.so.1.5 и использует его soname of xyz.so.1 для хранения в исполняемом файле. Затем, когда вы запускаете исполняемый файл, он пытается загрузить xyz.so.1, который укажет на конкретный xyz.so.1.N (не обязательно версию 1.5).

Итак, вы можете установить xyz.so.1.6 и обновить ссылку xyz.so.1, чтобы указать на нее, а вместо этого будут использоваться уже связанные исполняемые файлы.

Одно из преимуществ этого многоуровневого метода заключается в том, что вы можете иметь несколько потенциально несовместимых библиотек с одним и тем же именем (xyz.so.1.*, xyz.so.2.*), но в каждой основной версии вы можете свободно обновлять их, поскольку они предполагаются для совместимости.

Когда вы связываете новые исполняемые файлы:

Те, кто связывается с xyz.so, получат последнюю версию последней версии.
Другие, связанные с xyz.so.1, получат последнюю небольшую версию определенной основной версии.
Другие ссылки, связанные с xyz.so.1.2, получат конкретную второстепенную версию определенной основной версии.

Теперь учтите этот последний абзац, когда мы рассмотрим ваш комментарий:

Теперь скажем, что я скомпилирую другую версию той же библиотеки со следующим именем-реальным, libmy.so.2.0. Руководство SONAME должно быть libmy.so.2.0.

Нет, я не верю. soname скорее всего будет libmy.so.2, чтобы вы могли сделать небольшие обновления в потоке 2.x и получить последнее поведение.

Ответ 2

При времени ссылки на приложение, если вы укажете -lmy, компоновщик будет искать файл с именем libmy.so. Он найдет этот файл и свяжет с ним исполняемый файл. Если этот файл является символической ссылкой, ваше приложение будет связано с мишенью символической ссылки.

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