Каждый раз, когда вы выпускаете библиотеку, он должен иметь другой номер версии. Тем не менее, некоторые выпуски вносят изменения во внутреннюю работу библиотеки, не затрагивая пользователей, кроме исправления ошибок. Другие выпуски могут также добавлять новые функции в библиотеку, но детали интерфейса всех существующих функций такие же, как и раньше, поэтому программное обеспечение, написанное для использования старой версии библиотеки, будет продолжать работать с новой версией. Другие изменения могут нарушить совместимость; функциональный интерфейс изменяется, структура изменяет размер или функция отбрасывается (или глобальная переменная - погибает мысль - изменения и т. д.).
Варианты с исправлением ошибок могут не документировать нумерацию библиотеки, но если вы ранее имели liberror.so.1.0.2, новая версия может быть liberror.so.1.0.3, изменение номера выпуска.
В версиях «дополнительных функций» должен быть указан новый младший номер, поэтому новая версия после liberror.so.1.0.2 может быть liberror.so.1.1.0.
Если вы нарушите совместимость, то вы используете новый номер версии, поэтому новая версия после liberror.so.1.0.2 может быть liberror.so.2.0.0.
код построен для использования liberror.so.1.0.2 могут и будет использовать либо liberror.so.1.0.3 или liberror-1.1.0 без проблем, но не будет пытаться использовать liberror.so.2.0.0 или более позднюю версию.
Какой код (через Binutils GNU стек, например) управления, какие версии будут связаны с, и такое поведение фиксируется или переопределение?
Хороший вопрос. Это мое понимание, но у меня могут быть некоторые детали неправильные (в этом случае кто-то, вероятно, укажет на ошибку моих путей). Теория выше хорошая, легко; это немного менее просто.
Возможно, вы заметили, что для библиотек существуют также пакеты «разработки», а также «стандартные» версии библиотек. Разница между ними является частью объяснения.
Если вы обычный пользователь, который не пишет программы, используя библиотеку, а просто запускает программы, написанные кем-то другим, вы обычно получаете один файл и одну символическую ссылку в каталоге установки.Продолжая с гипотетическим liberror.so.1.0.2 примера (установлен в /usr/local/lib), вы найдете в базовом выпуске:
liberror.so.1.0.2 — the real shared object
liberror.so.1 — symlink to the the real shared object
Если вы установили версию разработки, вы, вероятно, найти некоторые файлы заголовков в /usr/local/include, некоторые страницы человека (возможно, в /usr/local/man, возможно, в /usr/share вместо), и дополнительный линке:
liberror.so — another symlink, either to liberror.so.1 or to liberror.so.1.0.2
Когда программа с использованием компилируется, можно указать:
gcc -I/usr/local/include usererror.c -o usererror -L/usr/local/lib -lerror
Это будет связывать с именем liberror.so, но чтение метаданных из файла liberror.so.1.0.2, он будет знать, что версия, чтобы использовать это liberror.so.1.0.2 или позже (но не liberror.so.2.0.0 или позже).
Теперь предположим, что вы обновили установку до liberror.so.2.0.0. Теперь у вас есть файлы:
liberror.so.1.0.2 — the real shared object
liberror.so.1 — symlink to the the real shared object
liberror.so.2.0.0 — the real shared object
liberror.so.2 — symlink to the the real shared object
liberror.so — another symlink, either to liberror.so.2 or to liberror.so.2.0.0
Старый код построен для использования liberror.so.1 все еще работает с помощью этой библиотеки. Новый код, созданный для использования liberror.so.2, также работает с использованием новой библиотеки. И при ссылке время, новые программы забирают liberror.so.2.0.0 через символическую связь liberror.so.
Вы можете управлять им, чтобы по умолчанию в вашей системе было liberror.so.1, установив символическую ссылку liberror.so, чтобы указать на liberror.so.1.0.2. Единственная сложная задача - убедиться, что для компиляции доступны правильные версии заголовков. Плохая идея построить с заголовками для liberror.so.2 и ссылку с liberror.so.1, потому что одна вещь, которую вы точно знаете, это то, что интерфейсы разные!
Некоторые необработанные данные с компьютера Red Hat Enterprise Linux 5 (RHEL5) x86_64.
$ cd /lib64
$ ls libc*
-rwxr-xr-x 1 root root 1713088 2009-01-05 16:32 libc-2.5.so
lrwxrwxrwx 1 root root 11 2012-02-22 15:05 libcap.so -> libcap.so.1
lrwxrwxrwx 1 root root 14 2012-02-22 15:05 libcap.so.1 -> libcap.so.1.10
-rwxr-xr-x 1 root root 17384 2006-11-14 01:36 libcap.so.1.10
-rwxr-xr-x 1 root root 197744 2009-01-05 16:32 libcidn-2.5.so
lrwxrwxrwx 1 root root 14 2012-02-22 15:05 libcidn.so.1 -> libcidn-2.5.so
lrwxrwxrwx 1 root root 17 2012-02-22 15:05 libcom_err.so.2 -> libcom_err.so.2.1
-rwxr-xr-x 1 root root 10000 2008-09-30 13:27 libcom_err.so.2.1
-rwxr-xr-x 1 root root 48600 2009-01-05 16:32 libcrypt-2.5.so
-rwxr-xr-x 1 root root 1048728 2005-10-31 06:47 libcrypto.so.0.9.6b
-rwxr-xr-x 1 root root 1365504 2008-12-16 08:09 libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.2 -> libcrypto.so.0.9.6b
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.4 -> libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 19 2012-02-22 15:05 libcrypto.so.6 -> libcrypto.so.0.9.8e
lrwxrwxrwx 1 root root 15 2012-02-22 15:05 libcrypt.so.1 -> libcrypt-2.5.so
lrwxrwxrwx 1 root root 11 2012-02-22 15:05 libc.so.6 -> libc-2.5.so
$
Вы можете увидеть libc.so.6 является символической ссылкой на libc-2.5.so. Вы также можете использовать несколько версий libcrypto, не включая библиотеку времени соединения libcrypto.so. Вы также можете увидеть библиотеки с двумя частями номера версии и т. Д. Представленные библиотеки: libc, libcap, libcidn, libcom_err, libcrypt и libcrypto.
'libfoo.so.version.minor.release' –