Может кто-нибудь объяснить, как называются библиотеки Linux?

Question

Когда я создаю библиотеку в Linux, я использую этот метод:

1. Сборка: libhelloworld.so.1.0.0
2. Ссылка: libhelloworld.so.1.0.0 libhelloworld.so
3. Ссылка: libhelloworld.so.1.0.0 libhelloworld.so.1

Управление версиями таково, что если вы измените общедоступные методы, вы можете, например, создать libhelloworld.so.2.0.0 (и оставить 1.0.0 там, где он есть), чтобы приложения, использующие старую библиотеку, не сломаться.

Однако какой смысл называть его 1.0.0 - почему бы просто не использовать libhelloworld.so и libhelloworld.so.1?

Также , лучше ли называть вашу библиотеку, например, с помощью 1.0.0 или только 1?

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

Или:

g++ ... -Wl,-soname,libhelloworld.1.0.0

Answer 1

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Давайте рассмотрим 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. Выглядит как разработчик надоело безответственным разработчикам приложений.

Answer 5

Есть несколько способов назвать libs:

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