> > On May 27, 2012, at 11:31 PM, Artur Kielak wrote: > > > I think than You run older version tcpdump: > > You can't use ldd to find out the version of tcpdump; you have to run > "tcpdump -h" to get the version of tcpdump. > > > This is the answer: > > libpcap.so.0.8 => /usr/lib/libpcap.so.0.8 (0x002c9000) > > Linked to old version. > > Just because the shared library file happens to end with ".0.8", that doesn't > mean that it's version 0.8, or version 0.8.x for any value of x, of libpcap. > I don't know what distribution Ajith is using, but, for example, Debian still > calls the shared library "libpcap.so.0.8" even though it's based, presumably, > on libpcap 1.1.1 in stable: > > http://packages.debian.org/stable/libs/libpcap0.8 > > and libpcap 1.2.1 in testing: > > http://packages.debian.org/testing/libs/libpcap0.8 > > and unstable: > > http://packages.debian.org/unstable/libs/libpcap0.8 > > and Ubuntu, being Debian-based, does the same. Presumably the version number > didn't change because the binary interface to the library hasn't changed in a > backwards-incompatible fashion for ages (new routines and other new > capabilities have been added, so the binary of an app built with a *later* > shared version of the library won't work with an *earlier* shared version of > the library if they use those new routines or capabilities, but, modulo > library bugs, the binary of an app built with an *earlier* shared version of > the library should work with a *later* shared version of the library).- > This is the tcpdump-workers list. > Visit https://cod.sandelman.ca/ to unsubscribe. >
You're right Guy :) Thank you for your comment. I wanted to show a simple way to solve the problem Ajith on the latest dev libraries without going into details. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
