Re: Building tcpdump with static libraries

[Guy Harris <guy () alum mit edu>]

On May 28, 2012, at 2:28 AM, Ajith Adapa wrote:

> I am currently building tcpdump on Ubuntu

Given the "libpcap.so.0.8", I suspected you were either using Debian or a Debian derivative such as Ubuntu.

> $ ./tcpdump -h
> tcpdump version 4.4.0-PRE_GIT_2012_05_28

OK, that's a *VERY* recent version (as indicated by the the "On May 28, 2012, at 2:28 AM" above and the "2012_05_28" in 
the version string) of tcpdump - and it's from the Git trunk (or whatever it's called in Git), given the 
"4.4.0-PRE_GIT_" in the version string.

> libpcap version 1.0.0

OK, that's presumably the shared library that came with the system.

> I even tried adding -static flag but I have got errors regarding dlopen and
> dlclose.

Many UN*Xes make it difficult to link a program 100% statically.  (Some make it *impossible*, by not supplying a static 
version of the "system library" - the one usually called "libc", but called "libSystem" on the UN*X with the largest 
desktop market share, that being one of the UN*Xes that does not supply a static version of that library.)

One way in which it can be difficult to link a program 100% statically is that:

        many UN*Xes have a plug-in architecture for routines such as getpwuid() and getpwnam(), so that support for 
looking up user login names and user IDs can be configured to look in a local database, look up over the network using 
NIS, look up over the network using NIS+, look up over the network using LDAP, etc., and even add additional mechanisms 
without having to change the system library to support it (this is called the Name Service Switch) - GNU libc, used as 
the "system library" on most Linux distributions, does this, as do man other UN*X system libraries - with the plugins 
loaded using the run-time linker;

        programs linked 100% statically don't have access to the run-time linker;

and that's probably what's causing your dlopen() and dlclose() errors (those are the run-time linker APIs used to load 
and unload code modules at run time).

(Note also that many UN*Xes make no promise that the binary interface between user-mode code and the kernel for 
particular operations will not change incompatibly from release to release; instead, they make a promise that the 
binary interface used to call routines that turn into system calls will not change incompatibly from release to 
release.  This means that a program statically linked with the system library, so that the executable image contains 
binary code that traps into the kernel, is not guaranteed to run on future OS releases, but a program dynamically 
linked with the system library, so that the executable image does *not* contain that code but dynamically links to the 
version of the code in question on the version of the OS on which it's running, is guaranteed to do so, modulo bugs in 
the program and the OS.)

So you should probably *NOT* try statically linking with all libraries - try, instead, statically linking with all 
libraries *other* than libc, or with whatever libraries with which you need to link statically.

The OS that introduced the dynamic-linking model used by most UN*Xes - SunOS 4.0 - had a "-B" option to the linker, 
which took arguments "static" and "dynamic", and could be used *multiple* times in a linker (or C compiler) command 
line, e.g.

        cc -o executable main.o scanner.o processor.o writer.o -B static -lfoo -B dynamic -lbar

which would cause "executable" to be linked statically with libfoo but dynamically with libbar and the system library.

A quick look at

        http://sourceware.org/binutils/docs-2.22/ld/Options.html

seems to indicate that the version of the GNU linker (the one used as the linker on most Linux distributions) supports 
"-static" and "-shared" in the same fashion (and supports "-Bstatic" and "-Bdynamic" as aliases for them, presumably 
for compatibility with the SunOS 4.x and SVR4 linkers).  Try putting "-shared" either after all of the -l options or 
before the first library that *doesn't* have to be linked statically.-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.