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

Ответ 1

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

Рассмотрим пример 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, который нарушает совместимость интерфейса с предыдущей версией, I может установить его как 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. Похоже, разработчик устали от безответственных разработчиков приложений.

Ответ 2

Способ создания версии x.y.z выглядит следующим образом:

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

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

Ответ 3

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

Согласно 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. Но это обсуждение в другое время.:)

Ответ 4

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

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

Ответ 5

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

• Тип Solaris:.so → .so.1
• Стиль GNU:.so → .so.1 → .so.1.2.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