Re: [Wireshark-commits] rev 40436: /trunk-1.6/ /trunk-1.6/debian/: wireshark-common.files /trunk-1.6/epan/: Makefile.am /trunk-1.6/: make-version.pl /trunk-1.6/wiretap/: Makefile.am

[Guy Harris <guy () alum mit edu>]

On Jan 12, 2012, at 11:16 AM, Joerg Mayer wrote:

> Thanks for the pointer and the following explanations. Now that I feel I *may*
> have understood the numbering, I have a new proposal/question:
> As we strive to keep our libs downward compatible inside a stable release
> (i.e. the newer libs should be usable with lower versions of plugins and
> wireshark?) we may want to add -version as well?

Presumably you mean "add -release".

> How about naming the libs
> for Wireshark <major>.<minor>.<release> something like
> -release <major>.<minor> -version-info <release>:0:<release>?

I'm not sure they're supposed to be used together, at least in that fashion.  I tried changing epan/Makefile.am to pass

        -release 1.7.1 -version-info 0:1:0

and what I got was libwireshark-1.7.1.0.0.1.dylib and libwireshark-1.7.1.0.dylib, which have a lot more components in 
the name than is normally seen..  Without -release, I get libwireshark.0.0.1.dylib and libwireshark.0.dylib, which is 
more like what version numbers should be.

The libtool documentation says

        -release release
                Specify that the library was generated by release release of your package, so that users can easily 
tell which versions are newer than others. Be warned that no two releases of your package will be binary compatible if 
you use this flag. If you want binary compatibility, use the -version-info flag instead (see Versioning).

The "use the -version-info flag instead" seems to suggest that -version-info is intended to be an alternative to 
-release.  Section 7.4 "Managing release information" of the libtool documentation says

        Often, people want to encode the name of the package release into the shared library so that it is obvious to 
the user which package their programs are linked against. This convention is used especially on GNU/Linux:

             trick$ ls /usr/lib/libbfd*

             /usr/lib/libbfd.a           /usr/lib/libbfd.so.2.7.0.2
             /usr/lib/libbfd.so
             trick$

        On ‘trick’, /usr/lib/libbfd.so is a symbolic link to libbfd.so.2.7.0.2, which was distributed as a part of 
‘binutils-2.7.0.2’.

        Unfortunately, this convention conflicts directly with libtool's idea of library interface versions, because 
the library interface rarely changes at the same time that the release number does, and the library suffix is never the 
same across all platforms.

        So, in order to accommodate both views, you can use the -release flag in order to set release information for 
libraries for which you do not want to use -version-info. ...

which further seems to suggest that -release and -version-info are not intended to be used together.

That section continues:

        ... For the libbfdexample, the next release that uses libtool should be built with ‘-release 2.9.0’, which will 
produce the following files on GNU/Linux:

             trick$ ls /usr/lib/libbfd*

             /usr/lib/libbfd-2.9.0.so     /usr/lib/libbfd.a
             /usr/lib/libbfd.so
             trick$

                In this case, /usr/lib/libbfd.so is a symbolic link to libbfd-2.9.0.so. This makes it obvious that the 
user is dealing with ‘binutils-2.9.0’, without compromising libtool's idea of interface versions.

        Note that this option causes a modification of the library name, so do not use it unless you want to break 
binary compatibility with any past library releases. In general, you should only use -release for package-internal 
libraries or for ones whose interfaces change very frequently.

What they mean there is that, with that name, the library is "libbfd-2", version 9.0.

The shared library version number scheme used in ELF-based systems is based on the one in SunOS 4.x (because the ELF 
scheme originally came from System V Release 4, which was produced by a joint AT&T/Sun project that introduced a SunOS 
4.x-derived shared library mechanism).  In the SunOS 4.x scheme, libraries had a major version number, which changed 
whenever the library changed in a non-backwards-binary-compatible fashion, and a minor version number, which changed 
whenever the library changed in a backwards-binary-compatible but not forwards-binary-compatible fashion (e.g., 
introducing a new routine).

That scheme isn't oriented towards matching project version numbers to library version numbers.

Given that the major version number of a shared library should change if and only if you make a 
backwards-binary-incompatible change to the library, which means that the library version number can track the project 
version number only if the project changes the major version number whenever it makes a backwards-binary-incompatible 
change to the library - which we don't do.


___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe