Wireshark mailing list archives

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


From: Guy Harris <guy () alum mit edu>
Date: Thu, 12 Jan 2012 01:35:47 -0800


On Jan 11, 2012, at 4:48 PM, Sam Roberts wrote:

On Wed, Jan 11, 2012 at 4:31 PM, Joerg Mayer <jmayer () loplof de> wrote:
On Wed, Jan 11, 2012 at 05:00:57PM +0000, gerald () wireshark org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=40436
User: gerald
Date: 2012/01/11 09:00 AM

Log:
 Have "make-version.pl -v" update the library revision information for
 libwireshark and libwiretap. The source code for each changes with every
 release and according to the libtool documentation we should increment
 the revision number. (wsutil hardly ever changes so we don't update it
 here.)

libwiretap_la_LDFLAGS = -version-info 1:6:0 -export-symbols wtap.sym @LDFLAGS_SHAREDLIB@

Why not mimic the Wireshark version? so instead of 1:6:0 use 1:6:4 for wireshark
1.6.4? Would make it trivial to generate the library version number.

http://www.sourceware.org/autobook/autobook/autobook_91.html

The key bit of which is

        It is important to note from the outset that the version number of your project is a very different thing to 
the version number of any libraries shipped with your project.

Do not confuse the colons with periods; the libtool library version is {current}:{revision}:{age}, and those aren't 
major/minor/dot-dot version number components.  {revision} actually changes more often than {age}!

        If you have changed any of the sources for this library, the revision number must be incremented. ...

        If the new interface is a superset of the previous interface (that is, if the previous interface has not been 
broken by the changes in this new release), then "age" must be incremented. ...

        If the new interface has removed elements with respect to the previous interface, then you have broken backward 
compatibility and "age" must be reset to `0'. ...

so, for example, for libwireshark, every time a new Wireshark release comes out that changes anything under the epan 
directory, the middle number changes, but the first number should change only if we export new routines from 
libwireshark or add new capabilities to those routines (e.g., a new FT_ value) or if we make any 
non-backwards-binary-compatible change to libwireshark, and the third number should, in most cases, be incremented 
every time we export new routines and add new capabilities *without* making any non-backwards-binary-compatible change 
and reduced any time we make any non-backwards-binary-compatible change (reduced to a value that, when subtracted from 
the first number, gives the value of the first number for the oldest library version with which we're still 
backwards-binary-compatible, which could well mean "reduced to 0").

(This is tricky, and either

        1) the vendors of some libraries, such as libpng and libfreetype, get it wrong

or

        2) the developers of libtool don't understand the way library versioning on Mac OS X works

or

        3) the way library versioning on Mac OS X works is designed around a run-time linker and a usage model a bit 
different from that of other UN*Xes and libtool doesn't really get it (short version: you can "weakly import" externals 
from a shared library, meaning that if they're present you can use them and if they're *not* present pointers to the 
weakly-imported functions and maybe variables are null - yes, that violates standard C - and programs will check for 
null function/method/{whatever it would be in Objective-C} pointers and either not use or work around the lack of the 
missing capabilities if the pointers are null)

or

        4) people should build "product" binaries for Mac OS X against the SDK, *NOT* against the installed libraries

or some combination of the above.

That's why we get complaints such as

        http://ask.wireshark.org/questions/3868/mac-osx-1063-when-i-open-wireshark-it-shows-on-dock-then-closes

(because a software update picks up a new version of an upstream library, and the upstream library ends up getting a 
different *major* version number just because it adds new functionality - after all, programs built with that version 
won't work on older minor OS releases, and I guess the "can only find an older minor version" warning that I think 
shows up on other UN*Xes was considered an insufficient response, perhaps because the program could fail later on if it 
really needs a routine only found in the newer version).)
___________________________________________________________________________
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


Current thread: