Ответ 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 и получить последнее поведение.