On Mon, Dec 24, 2001 at 09:54:13AM -0600, Michael D. Schleif wrote:
> I need to compile tcpdump and libpcap or a linux distribution using
> kernel 2.2.19 and glibc 2.0. I have built a debian slink system on
> which to develop.
>
> I have what I believe to be a workable compile; but, I am confused on
> several issues:
>
> [1] What are differences between libpcap.a and the libpcap.so* files?
".a" files are "a"rchive-library files, and ".so" files are "s"hared
"o"bject files.
The latter are shared libraries; a program linked with a shared library
is attached to the library when it starts up. The executable image file
for that program does not include the code from the library; instead, it
includes information to allow the "run-time linker" to find the right
library.
The former are non-shared libraries; a program linked with a non-shared
library is not attached to the library when it starts up - instead, when
the executable image file for the program is built, the code for the
library routines called by that program (and for library routines those
other routines call, etc.) is extracted from the archive library file
and put into the executable image for the program.
(If you're familiar with Windows, think of ".a" files as being like
".lib" files, and ".so" files as being like ".dll" files.)
> [2] How do programs know which libpcap.a to use?
When the program's executable image is built, the linker ("ld", although
it's usually run by the "gcc", "cc", "g++", etc. command) searches in a
number of directories for libraries specified with "-l" flags, e.g.
"-lpcap".
By default, "/usr/lib" is one such directory, but "/usr/local/lib"
isn't. You'd have to specify a "-L/usr/local/lib" command-line flag to
the linker (or compiler), before specifying "-lpcap", to get the version
in "/usr/local/lib".
> [3] Why is the newer libpcap.a 50% larger than the older one?
Because it has more features? :-)
> [4] Should there be a libpcap.so.0.6.2?
It might be nice if there were; unfortunately, the way that a shared
library is built is very platform-dependent, so, in order to make a
*portable* distribution of libpcap (one that can be built on a variety
of UNIX-compatible systems), we'd have to use libtool, and we haven't
yet done that. (From my experience with it as an Ethereal developer,
it's a bit of a pain to use. Perhaps later versions will reduce the
level of pain.)
> If so, should it be linked to libpcap.so and libpcap.so.0 ?
If there were one, then, on Linux systems, it would be linked to those
files (or, rather, those files would be linked to it).
(On other systems that also use System V Release 4-style shared
libraries, there might only be a "libpcap.so.0" with "libpcap.so" linked
to it; the scheme with the three names for the library is a Linuxism,
which, for example, the BSDs and Solaris haven't adopted. The run-time
linker doesn't care about the "real name", such as "libpcap.so.0.4a6" or
"libpcap.so.0.6.2"; it only cares about the "soname", which such as
"libpcap.so.0". The "real name" is used, on Linux systems, as a way of
letting the user know what version of the library is installed.)
See
http://www.linuxdoc.org/HOWTO/Program-Library-HOWTO/shared-libraries.html
for information on this.
> [5] Which libpcap* will be used during a compile of tcpdump on this
> system?
It depends.
If you compile without a "-L" flag, the linker will search only in
"/usr/lib". Unless you've specified a flag telling the linker to link
with non-shared libraries, it'll use the "libpcap.so" shared library,
linking it with "libpcap.so.0", which, in "/usr/lib", means it'll use
"libpcap.so.0.4a6".
If that's done, then the program will use "libpcap.so.0" when run. Note
that if, for example, you've installed a later version of the library,
or set LD_LIBRARY_PATH to search in other directories for libraries, or
configured the run-time linker to search in other directories, and those
directories have a later version of the libpcap shared library as
"libpcap.so.0", the program will use *that* version - there's no
guarantee that a program will, at run-time, be linked with the exact
same version of the library that it was linked with when built.
This has the advantage that you can drop in a new version of a shared
library, with bug fixes or other enhancements, and programs linked with
the shared version of the library will automatically get those bug fixes
or other enhancements (assuming that the program doesn't have to be
modified to use the enhancements).
This also has the disadvantage that you can drop in a new version of a
shared library, with shiny new bugs, and programs linked with the shared
version of the library might automatically get those bugs. :-)
If you *have* specified a flag (e.g., "-static") telling the linker to
link with non-shared libraries, it'll use the "libpcap.a" non-shared
library. If you've compiled without a "-L" flag, it'll use the
"libpcap.a" in "/usr/lib".
If you compile with "-L/usr/local/lib", the linker will search in
"/usr/local/lib" before searching in "/usr/lib". If so, it'll use the
"libpcap.a" in "/usr/local/lib".
Note that if you do that, you should *also* compile with
"-I/usr/local/include", so that the program is compiled with the header
files for libpcap 0.6.2, as well as being linked with the library file
for libpcap 0.6.2.
> [6] Why is there such a difference in sizes for tcpdump?
>
> -rwxr-xr-x 1 root staff 291358 Dec 23 16:24
> /usr/local/sbin/tcpdump
> -rwxr-xr-x 1 root root 102352 Mar 29 1998 /usr/sbin/tcpdump
>
> Even after strip:
>
> -rwxr-xr-x 1 root staff 252912 Dec 23 16:26
> /usr/local/sbin/tcpdump
As per what I said above:
".a" files are "a"rchive-library files, and ".so" files are "s"hared
"o"bject files.
The latter are shared libraries; a program linked with a shared library
is attached to the library when it starts up. The executable image file
for that program does not include the code from the library; instead, it
includes information to allow the "run-time linker" to find the right
library.
The former are non-shared libraries; a program linked with a non-shared
library is not attached to the library when it starts up - instead, when
the executable image file for the program is built, the code for the
library routines called by that program (and for library routines those
other routines call, etc.) is extracted from the archive library file
and put into the executable image for the program.
"/usr/sbin/tcpdump" is probably linked with the shared version of the
library "/usr/lib/libpcap.so.0", and "/usr/local/sbin/tcpdump" is
probably linked with the non-shared version of the library
"/usr/local/lib/libpcap.a". This means that "/usr/sbin/tcpdump" doesn't
include any code from libpcap, it only includes an indication that it
should be linked to "libpcap.so.0" at run-time to get that code, but
"/usr/local/sbin/tcpdump" includes code from "/usr/local/lib/libpcap.a".
Run "ldd /usr/sbin/tcpdump" and "ldd /usr/local/sbin/tcpdump"; the
former will probably indicate that "/usr/sbin/tcpdump" is dynamically
linked with "libpcap.so.0" and that "/usr/local/sbin/tcpdump" isn't
dynamically linked with libpcap.
This is all, by the way, not specific to libpcap; it's the way shared
libraries work on a number of UNIX-compatible systems, including
derivatives of System V Release 4 such as Solaris 2, Solaris 7, and
Solaris 8, as well as Linux distributions and recent versions of
{Free,Net,Open}BSD. (Older versions of the BSDs are similar, but they use
a SunOS 4.x-style shared library mechanism, which is similar to, but not
exactly the same as, the System V Release 4 scheme used by the newer
BSDs and by current Linux distributions. *Really* old Linux systems,
with 1.x kernels, used a significantly different shared library
mechanism.)
Note, by the way, that, although the version of libpcap in Debian
"stable" is 0.4a6 - I have *no* idea why 0.4a6 is so common, given that
the final 0.4 came out not long after the alpha6 version came out, many
years ago - the version in "testing" is 0.6.2 (so 0.6.2 should be in
woody).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
