Может кто-нибудь объяснить насчет именования библиотек Linux?

Из старого электронного письма, которое я отправил коллеге по этому вопросу:

Давайте посмотрим на libxml в качестве примера. Прежде всего, общие объекты хранятся в /usr/lib с рядом символических ссылок, представляющих доступную версию библиотеки:

lrwxrwxrwx 1 root root     16 Apr  4  2002 libxml.so -> libxml.so.1.8.14
lrwxrwxrwx 1 root root     16 Apr  4  2002 libxml.so.1 -> libxml.so.1.8.14
-rwxr-xr-x 1 root root 498438 Aug 13  2001 libxml.so.1.8.14

Если я являюсь автором libxml и выпущу новую версию libxml 2.0.0, которая нарушает совместимость интерфейса с предыдущей версией, я могу установить ее как libxml.so.2 и libxml.so.2.0.0. Обратите внимание, что программист приложения должен нести ответственность за то, на что он ссылается. Если я действительно анал, я могу напрямую связать libxml.so.1.8.14, и любая другая версия приведет к тому, что моя программа не запустится. Или я могу сделать ссылку на libxml.so.1 и надеяться, что разработчик libxml не нарушит совместимость символов для меня в версии 1.X. Или, если вам все равно и вы безрассудны, просто дайте ссылку на libxml.so и получите любую версию. Иногда, когда этим занимается достаточное количество людей, автору библиотеки приходится проявлять творческий подход к более поздним версиям. Следовательно, libxml2:

lrwxrwxrwx 1 root root     17 Apr  4  2002 libxml2.so.2 -> libxml2.so.2.4.10
-rwxr-xr-x 1 root root 692727 Nov 13  2001 libxml2.so.2.4.10

Обратите внимание, что в этом файле нет libxml2.so. Похоже, разработчику надоели безответственные разработчики приложений.

То, как вы должны сформировать версию x.y.z, выглядит следующим образом:

1. Первая цифра (x) — это версия интерфейса библиотеки. Всякий раз, когда вы меняете общедоступный интерфейс, это число увеличивается.
2. Второе число (y) — это номер версии текущего интерфейса. Всякий раз, когда вы вносите внутренние изменения без изменения общедоступного интерфейса, это число увеличивается.
3. Третье число (z) — это не номер сборки, это число обратной совместимости. Это говорит вам, сколько предыдущих интерфейсов поддерживается. Так, например, если версия интерфейса 4 является строго надмножеством интерфейсов 3 и 2, но полностью несовместима с 1, то z=2 (4-2 = 2, наименьший поддерживаемый номер интерфейса)

Таким образом, числа x и z очень важны для системы, чтобы определить, может ли данное приложение использовать данную библиотеку, учитывая, для чего приложение было скомпилировано. Число y в основном предназначено для отслеживания исправлений ошибок.

Соглашения об именах библиотек

Согласно Wheeler, у нас есть real name, soname и linker name:

  Real name  libfoo.so.1.2.3
     Soname  libfoo.so.1
Linker name  libfoo.so

real name — это имя файла, содержащего фактический код библиотеки. soname обычно является символической ссылкой на real name, и ее номер увеличивается, когда интерфейс изменяется несовместимым образом. Наконец, linker name — это то, что компоновщик использует при запросе библиотеки, то есть soname без указания номера версии.

Итак, чтобы сначала ответить на ваш последний вопрос, вы должны использовать soname, libhelloworld.so.1 для опции компоновщика при создании общей библиотеки:

g++ ... -Wl,-soname,libhelloworld.so.1 ...

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

Соглашения о нумерации библиотек

Существует некоторая путаница в отношении назначения и назначения каждого из чисел в real name библиотеки. Лично я считаю, что в проекте Apache Portable Runtime Project хорошо объясняются правила, когда каждое число следует увеличить.

Короче говоря, номера версий можно представить как libfoo.MAJOR.MINOR.PATCH.

• PATCH увеличивается для изменений, совместимых как в прямом, так и в обратном направлении с другими версиями.
• MINOR следует увеличить, если новая версия библиотеки является исходным кодом и двоичным кодом, совместимым со старой версией. Различные младшие версии обратно совместимы, но не обязательно совместимы друг с другом вперед.
• MAJOR увеличивается, когда вносится изменение, нарушающее работу API или иным образом несовместимое с предыдущей версией.

Это означает, что версии PATCH могут отличаться только внутренне, например, способом реализации функции. Изменение API, подписи общедоступных функций или интерпретации параметров функций запрещено.

В новом выпуске MINOR могут быть представлены новые функции или константы, а существующие функции объявлены устаревшими, но не может быть удалено ничего, что доступно извне. Это обеспечивает обратную совместимость. Другими словами, дополнительный выпуск 1.12.3 можно использовать для замены любой другой 1.12.x или более ранней версии, например 1.11.2 или 1.5.0. Тем не менее, это не замена 1.16.1, так как различные второстепенные версии не обязательно совместимы вперед.

Любые изменения могут быть внесены с выпуском новой версии MAJOR; константы могут быть удалены или изменены, (устаревшие) функции могут быть удалены и, конечно же, любые изменения, которые обычно увеличивают число MINOR или PATCH (хотя, возможно, стоит перенести такие изменения и на предыдущую версию MAJOR).

Конечно, есть факторы, которые могут еще больше усложнить это; возможно, вы разработали свою библиотеку таким образом, что один и тот же файл может одновременно хранить несколько версий, или вы можете использовать соглашение libtool о current:revision:age. Но это разговор в другой раз. :)

Основное преимущество этого метода заключается в том, что пользователи могут легко узнать, какая у них версия библиотеки. Например, если я знаю, что ошибка, которую я получаю, была исправлена ​​в 1.0.4, я могу легко проверить, с какой версией библиотеки я связываюсь, и узнать, правильный ли это способ исправить ошибку.

Этот номер называется «версия общего объекта» или «версия» и является частью двоичного стандарта ELF. У IBM есть хороший обзор ELF на http://www.ibm.com/developerworks/power/library/pa-spec12/.

Существует несколько способов назвать библиотеки:

1. В стиле Solaris: .so -> .so.1
2. Стиль GNU: .so -> .so.1 -> .so.1.2.3
3. Случайно: .so -> .so.1.2

Видеть:

https://blogs.oracle.com/ali/entry/how_to_name_a_solaris http:// www.gnu.org/software/libtool/manual/libtool.html#Versioning