Управление версиями общих объектов работает следующим образом:
Когда вы создаете общий объект, вы даете ему реальное имя и 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 из xyz.so.1.
Когда компоновщик связывается в xyz.so, он следует по ссылкам вплоть до xyz.so.1.5 и использует его SONAME из 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 и получать последние сведения.