Re: [Wireshark-dev] [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
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 +, ger...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=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
Re: [Wireshark-dev] [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
On Jan 12, 2012, at 1:35 AM, Guy Harris wrote:
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 +, ger...@wireshark.org wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=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'. ...
Oh, and
If the interface has changed, then current must be incremented, and
revision reset to `0'. This is the first revision of a new interface.
Which seems to indicate, BTW, that if Wireshark 1.8.0 changes the libwireshark
ABI in a non-backwards-binary-compatible way (which it does, given that it gets
rid of FT_EBCDIC in favor of using ENC_EBCDIC with
FT_STRING/FT_STRINGZ/FT_UINT_STRING), the version info for the 1.8.0 version of
libwireshark should be 2:0:0, *NOT* 1:8:0! (I.e., it's a new interface number,
as it's not backwards-binary-compatible, hence {current} changes from 1 to 2
and {revision} resets to 0; the new revision is not backwards-compatible any
previous version, so {age} resets to 0.)
___
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
Re: [Wireshark-dev] Windows build environment
-Original Message- From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev- boun...@wireshark.org] On Behalf Of Joerg Mayer Sent: 12 January 2012 00:19 To: Developer support list for Wireshark Subject: Re: [Wireshark-dev] Windows build environment On Wed, Jan 11, 2012 at 11:23:21AM -, Graham Bloice wrote: On Jan 6, 2012, at 7:46 AM, Graham Bloice wrote: I've also wondered about moving on from nmake and converting to MSBuild. This is only usable from VS2008 or later though. Any thoughts on that? If we do so, can we continue to have lists of source files in Makefile.common, rather than, say, having to duplicate such a list in other files (which developers might forget to do)? Or, at least, can we automatically generate the relevant MSBuild files from files such as Makefile.common? Although I haven't investigated I would expect MSBuild to be able to absorb such input and make it useable, either directly or by a task to generate the required file. As an alternative: How about making building with cmake work for Windows? After that, maybe the following article has some clues: http://stackoverflow.com/questions/1459482/how-to-use-cmake-for-non- interactive-build-on-windows I'm willing to support anyone who is willing to tackle this, it's just that I don't have a Windows system to do this on my own. My initial motivation was more about reducing dependencies on stuff that Windows folks don't normally have installed, e.g. Cygwin, and also to move things forward a bit in terms of supported build technologies, although I don't suppose nmake is going away anytime soon. Last time I looked at CMake on Windows it didn't work for me, but I didn't look too hard. IIUC CMake is a Makefile generator, can it do all the stuff we currently do in nmake which is a fair bit more than just working out dependencies and compiling and linking the required modules? CMake's ability to generate Visual Studio project files could be attractive to some as well. ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/11/2012 06:04 PM, Gerald Combs wrote: On 1/10/12 2:29 PM, Gerald Combs wrote: On 1/10/12 2:09 PM, Balint Reczey wrote: diff --git a/debian/wireshark-common.files b/debian/wireshark-common.files index 41341be..4403c04 100644 --- a/debian/wireshark-common.files +++ b/debian/wireshark-common.files @@ -5,7 +5,7 @@ /usr/bin/text2pcap /usr/bin/rawshark /usr/lib/wireshark/libwireshark.so.1 -/usr/lib/wireshark/libwireshark.so.1.1.0 +/usr/lib/wireshark/libwireshark.so.1.1.1 /usr/lib/wireshark/libwiretap.so.1 /usr/lib/wireshark/libwiretap.so.1.0.1 /usr/lib/wireshark/libwsutil.so.1 Unfortunately I can't commit it now. It's a little late for that now at any rate. :) I modified make-version.pl to update the libwireshark and libwiretap revision numbers in accordance with the libtool documentation. I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. Running the ACC script and updating the version based on the result (possibly using a script) would give the right new version. Cheers, Balint commit baada8699e2365b3de312bf5f8825710dee34aff Author: Gerald Combs ger...@wireshark.org Date: Wed Jan 11 17:00:56 2012 + 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.) svn path=/trunk-1.6/; revision=40436 ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/11/2012 08:37 AM, Harper wrote: Balint Reczeybalint.rec...@ericsson.com wrote in news:4f09f7b3.2000...@ericsson.com: Hi, I have run tools/git-compare-abis.sh on latest master-1.6 (wireshark-1.6.4-21-ga6c3642). The ABI is almost totally stable [1], which is very good sign for plugin developers and for anyone using Wireshark's libraries. :-) There is only a minor incompatibility in packet-zbee-zcl.h caused by changed constants, which could be fixed by not backporting r40133. Does this affect only ZigBee? Do I need to recompile plugins that have compiled with 1.6.0? Since our plugins are not ZigBee related I assume it's not necessary to compile and distribute them. The ABI stability should allow using these plugins for all 1.6.x version. So if there is an ABI change can do you describe it? I have updated the ABI compatibility report here: http://rbalint.cs.bme.hu/ws-ABI-1.6.4-1.6.5/ If you don't use ZigBee related #define-s, you will be fine. Cheers, Balint ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update Running the ACC script and updating the version based on the result (possibly using a script) would give the right new version. Is ACC available for Windows or OS X? I'd rather keep make-version.pl cross-platform if possible. BTW, what version of ACC do you have installed? All of my Ubuntu machines have 1.6 which seems to support a completely different set of options than the ones in the dumpabi makefile target. The home page at http://ispras.linux-foundation.org/index.php/ABI_compliance_checker has been down since September. ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 1/12/12 9:06 AM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update [ hit send too soon. ] We update the code in epan and wiretap in every release, which means the revision number should be incremented for libwireshark and libwiretap, correct? ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/12/2012 06:20 PM, Gerald Combs wrote: On 1/12/12 9:06 AM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update [ hit send too soon. ] We update the code in epan and wiretap in every release, which means the revision number should be incremented for libwireshark and libwiretap, correct? I can imagine a release without any change in those libraries, this is why I wrote that it may not be the proper approach, but you are correct, if there are only internal changes in both libs, we should update the revision for both. Since we can change the ABI as well I propose running ACC before the release and manually updating the versions properly or creating a script which updates the version numbers properly according to ACC. Cheers, Balint ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 01/12/2012 06:06 PM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update Running the ACC script and updating the version based on the result (possibly using a script) would give the right new version. Is ACC available for Windows or OS X? I'd rather keep make-version.pl cross-platform if possible. BTW, what version of ACC do you have installed? All of my Ubuntu machines have 1.6 which seems to support a completely different set of options than the ones in the dumpabi makefile target. The home page at http://ispras.linux-foundation.org/index.php/ABI_compliance_checker has been down since September. I use ABI compliance checker 1.21.12 Unfortunately the Debian package is outdated, but there is a packaged 1.96.1-1, waiting for sponsor: http://packages.qa.debian.org/a/abi-compliance-checker.html I'll give a try to 1.96.1-1. Since we don't version dll-s and I don't know anything about the OS X builds I'm okay with supporting only currently suppported OS-s. Cheers, Balint ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On 1/12/12 9:33 AM, Balint Reczey wrote: On 01/12/2012 06:20 PM, Gerald Combs wrote: On 1/12/12 9:06 AM, Gerald Combs wrote: On 1/12/12 1:59 AM, Balint Reczey wrote: I'm not sure that it is the proper approach. We don't have to update the library version if there is no change in the lib. The libtool documentation says If the library source code has changed at all since the last update, then increment revision (‘c:r:a’ becomes ‘c:r+1:a’). We update [ hit send too soon. ] We update the code in epan and wiretap in every release, which means the revision number should be incremented for libwireshark and libwiretap, correct? I can imagine a release without any change in those libraries, this is why I wrote that it may not be the proper approach, but you are correct, if there are only internal changes in both libs, we should update the revision for both. It's certainly possible to create a release that doesn't change libwireshark or libwiretap. We've done it a few times the past (e.g. 1.0.16 fixed some Windows DLL hijacking flaws), but that case is very rare. (In case you're wondering why I'm being stubborn about this, the Wireshark release checklist is currently *3 pages long*. Adding manual steps makes a long process even longer and makes it more error prone.) Since we can change the ABI as well I propose running ACC before the release and manually updating the versions properly or creating a script which updates the version numbers properly according to ACC. I propose running it as far in advance of each release as possible. :) Having something we could run as a Buildbot step (that is, a makefile target or a shell, Python, or Perl script) would be fantastic. ___ 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
Re: [Wireshark-dev] [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
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 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? How about naming the libs for Wireshark major.minor.release something like -release major.minor -version-info release:0:release? Ciao Jörg -- Joerg Mayer jma...@loplof.de We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ 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
Re: [Wireshark-dev] Wireshark ABI stability 1.6.4 - 1.6.5
On Jan 12, 2012, at 9:06 AM, Gerald Combs wrote: Is ACC available for Windows or OS X? I'd rather keep make-version.pl cross-platform if possible. This: http://forge.ispras.ru/projects/abi-compliance-checker/repository/entry/trunk/INSTALL.txt seems to suggest that the latest version, 1.9.1, does support Windows and Mac OS X. They also mention Linux and FreeBSD; my guess is that it could work on all ELF-based systems that use the GNU toolchain. It might also work on ELF-based systems that don't, e.g. Solaris, if you install GNU binutils. BTW, what version of ACC do you have installed? All of my Ubuntu machines have 1.6 which seems to support a completely different set of options than the ones in the dumpabi makefile target. The home page at http://ispras.linux-foundation.org/index.php/ABI_compliance_checker has been down since September. OK, so maybe you just ignore that site and look at the forge.ispras.ru site: http://forge.ispras.ru/projects/abi-compliance-checker instead. ___ 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
Re: [Wireshark-dev] pcapng, must opt_comment string be?0-terminated?
Thus wrote Chris Maynard (chris.mayn...@gtech.com): To avoid the possibility of reading past the end of option_content in the case when oh.option_length sizeof(option_content), I think it would be safer to do this instead: wblock-data.packet.opt_comment = g_strndup(option_content, MIN(oh.option_length, sizeof(option_content))) Note that this can't happen today because if the option length is greater than sizeof(option_content), then we never get there, yes, I saw the check before the g_strndup() but I think the implementation would work better to read as much as will fit into the buffer as possible, in this case the 1st 99 characters of the string (plus the NULL-terminator), rather than skipping it altogether. The comment next to option_content indicates, XXX - size might need to be increased, if we see longer options, so it's apparently a somewhat arbitrary limit. I think as pcapng sees more and more use, it's only a matter of time before longer and longer strings are added (or desired to be added). Even the examples shown at the end of section 2.5 of the pcapng spec illustrate some strings approaching that limit, and those strings do not seem overly long to me: This packet is the beginning of all of our problems / Packets 17-23 showing a bogus TCP retransmission, as reported in bugzilla entry 1486! / Captured at the southern plant / I've checked again, now it's working ok / ... You're right, 100 characters seems arbitrary and probably too small for many cases. I was wondering why we need a static buffer at all. It looks like the intention is to keep using the same buffer for each option that we parse. When reading an option, how about checking the length first and then allocating the buffer dynamically? We could then remove the g_strdup() as well and use the allocated buffer to pass the option on to wiretap etc. My understandig is that g_strdup() allocates a copy that the caller must free. I don't think that at the moment, anybody is freeing the copy for the comment (or for any other option). Best regards, Martin ___ 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
[Wireshark-dev] Fwd: [FOSDEM] Meeting rooms
Of the developers attending FOSDEM, who can run fastest? Original Message Subject: [FOSDEM] Meeting rooms Date: Thu, 12 Jan 2012 23:08:17 +0100 From: Pascal Bleser l...@fosdem.org To: fos...@lists.fosdem.org This year, we will provide two meeting rooms (aka BoF rooms) in the AW building. The idea here is that they are provided for unplanned or, rather, spontaneously planned and brief meetups. The planning system is as easy as it gets: each room will have a sheet of paper with a time grid next to it, and it's first come first served. A project or group of people may only take up to an hour per day. We won't enforce that unless someone complains to us, but anyway, keep in mind that a whole lot of projects and people are present at FOSDEM, and as many as possible should have a fair chance of using them if needed. Most specifically, they are _not_ a replacement for a devroom. cheers -- Pascal Bleser l...@fosdem.org http://fosdem.org/ FOSDEM 2012 ::: 4 + 5 February 2012 in Brussels, Belgium Free and Opensource Software Developers European Meeting ___ FOSDEM mailing list fos...@lists.fosdem.org https://lists.fosdem.org/listinfo/fosdem ___ 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
Re: [Wireshark-dev] [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
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 ATT/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:
