Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 40436: /trunk-1.6/ /trunk-1.6/debian
On Jan 11, 2012, at 4:48 PM, Sam Roberts wrote:
> On Wed, Jan 11, 2012 at 4:31 PM, Joerg Mayer <jmayer@xxxxxxxxx> wrote:
>> On Wed, Jan 11, 2012 at 05:00:57PM +0000, gerald@xxxxxxxxxxxxx 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).)
