On Jan 11, 2012, at 4:48 PM, Sam Roberts wrote:
> On Wed, Jan 11, 2012 at 4:31 PM, Joerg Mayer <jma...@loplof.de> wrote:
>> On Wed, Jan 11, 2012 at 05:00:57PM +0000, ger...@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-requ...@wireshark.org?subject=unsubscribe
