版本号，次要号码和版本号之间的差异 [英] Difference between version number, minor number and release number
问题描述
我正在阅读 http：//www.tldp。 org / HOWTO / Program-Library-HOWTO / shared-libraries.html 和我有一些问题。
版本，次要和版本号之间有什么区别？
soname的前缀是
lib，库的名称，短语.so，后跟一个句点和一个版本号， / p>
真实姓名会向soname添加一个句号，一个次要号码，另一个句号和版本号。
每次你释放库，它应该可以有不同的版本号。但是，有些版本只会更改库的内部工作，而不会影响用户除了修复错误。其他版本也可以向库添加新函数，但是所有现有函数的接口详细信息与以前相同，因此使用旧版本库的软件将继续使用新版本。其他更改可能会破坏向后兼容性;函数接口改变，结构改变大小，或者函数被丢弃（或者全局变量 - 消失思想 - 改变等）。
'版本可能不会重新编号的库，但如果你以前有 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 。
使用 .1.0.2 可以并将使用 liberror.so.1.0.3 或 liberror-1.1.0 没有问题，但不会尝试使用 liberror.so.2.0.0 或更高版本。
什么代码（例如在一个GNU binutils堆栈中）控制哪些版本将被链接，这是固定的还是可覆盖的行为？ / p>
好问题。这是我的理解，但我可能有一些细节错误（在这种情况下，有人可能会指出我的方式的错误）。上面的理论是一个很容易;这是一个不太容易。
您可能已经注意到，有'开发'包的库以及'标准'版本的库。它们之间的区别是解释的一部分。
如果你是一个普通的最终用户，不是使用库编写程序，而只是运行其他人编写的程序，那么通常在安装目录中最终会有一个文件和一个符号链接。继续假设的 liberror.so.1.0.2 示例（安装在 / usr / local / lib 中）会在基本版本中找到：
liberror.so.1.0.2 - 真正的共享对象
liberror.so .1 - 符号链接到真正的共享对象
如果你安装了开发版本，在 / usr / local / include 中找到一些头文件，一些手册页（可能在 / usr / local / man ，或许在 / usr / share 中），以及一个额外的符号链接：
liberror.so - 另一个符号链接，可以是liberror.so.1或者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 - 真正的共享对象
liberror.so.1 - 符号链接到真正的共享对象
liberror.so.2.0.0 - 真正的共享对象
liberror.so.2 - 到真正的共享对象的符号链接
liberror.so - another符号链接，或者到liberror.so.2或者到liberror.so.2.0.0
使用 liberror.so.1 仍使用该库运行。使用 liberror.so.2 构建的新代码也使用新库运行。在链接时，新程序通过符号链接 liberror.so 拾取 liberror.so.2.0.0 / p>
您可以控制它，使系统上的默认值仍然 liberror.so.1 c $ c> 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 。
I'm reading http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html and I had some questions.
What is difference between version, minor and release number? What is meant by the part "version number is incremented whenever the interface changes"?
The soname has the prefix
lib, the name of the library, the phrase.so, followed by a period and a version number that is incremented whenever the interface changes.The real name adds to the soname a period, a minor number, another period, and the release number.
Each time you release the library, it should arguably have a different version number. However, some releases only make changes to the internal workings of the library without affecting users at all other than by fixing bugs. Other releases may also add new functions to the library, but the interface details of all the existing functions are the same as before, so software written to use an older version of the library will continue to work with the new version. Other changes may break backwards compatibility; a function interface changes, a structure changes size, or a function is dropped (or a global variable — perish the thought — changes, etc).
The 'bug fix only' versions might not bother with renumbering the library, but if you previously had liberror.so.1.0.2, the new version might be liberror.so.1.0.3, a change in the release number.
The 'additional features' versions should be given a new minor number, so the new version after liberror.so.1.0.2 might be liberror.so.1.1.0.
If you break compatibility, then you use a new version number, so the new version after liberror.so.1.0.2 might be liberror.so.2.0.0.
Code built to use liberror.so.1.0.2 can and will use either liberror.so.1.0.3 or liberror-1.1.0 without problem, but will not attempt to use liberror.so.2.0.0 or later versions.
What code (in a GNU binutils stack, for example) controls which versions will be linked to, and is this behavior fixed or overridable?
Good question. This is my understanding, but I might have some details wrong (in which case, someone will probably point out the error of my ways). The theory above is nice an easy; this is a little less easy.
You may have noticed that there are 'development' packages for libraries as well as the 'standard' versions of the libraries. The difference between them is part of the explanation.
If you're an ordinary end user who is not writing programs using a library but simply running programs that someone else has written, then you typically end up with one file and one symlink in the installation directory. Continuing with the hypothetical liberror.so.1.0.2 example (installed in /usr/local/lib), you would find in the base release:
liberror.so.1.0.2 — the real shared object
liberror.so.1 — symlink to the the real shared object
If you installed the development version, you'd probably find some header files in /usr/local/include, some man pages (perhaps in /usr/local/man, perhaps in /usr/share instead), and an extra symlink:
liberror.so — another symlink, either to liberror.so.1 or to liberror.so.1.0.2
When the program using it is compiled, you might specify:
gcc -I/usr/local/include usererror.c -o usererror -L/usr/local/lib -lerror
This will link with the name liberror.so, but reading the metadata from the liberror.so.1.0.2 file, it would know that the version to use is liberror.so.1.0.2 or later (but not liberror.so.2.0.0 or later).
Now let's suppose you upgrade the installation to liberror.so.2.0.0. You now have files:
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
Old code built to use liberror.so.1 still runs using that library. New code built to use liberror.so.2 also runs using the new library. And at link time, new programs pick up liberror.so.2.0.0 via the symlink liberror.so.
You can control it so that the default on your system is still liberror.so.1 by adjusting the liberror.so symlink to point to liberror.so.1.0.2. The only tricky part is making sure that the correct versions of the headers are available for compilation. It is a bad idea to build with the headers for liberror.so.2 and link with liberror.so.1 because the one thing you know for sure is that the interfaces are different!
Some raw data from a Red Hat Enterprise Linux 5 (RHEL5) x86_64 machine.
$ 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
$
You can see the libc.so.6 is a symlink to libc-2.5.so. You can also a number of versions of libcrypto, not including the link-time library libcrypto.so. You can also see libraries with only two parts to the version number, etc. The represented libraries are libc, libcap, libcidn, libcom_err, libcrypt and libcrypto.
这篇关于版本号，次要号码和版本号之间的差异的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
