>Number:         2818
>Category:       lib
>Synopsis:       ld problems shown with libpcap.a and libpap.so.0.0
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Oct  7 12:20:01 1996
>Last-Modified:
>Originator:     Michael Graff
>Organization:
flame.org:  yes, we do know everything
>Release:        07-Oct-1996
>Environment:
	
System: NetBSD kechara.flame.org 1.2A NetBSD 1.2A (KECHARA) #1: Wed Sep 18 19:47:21 EDT 1996 explorer@kechara.flame.org:/usr/src/sys/arch/i386/compile/KECHARA i386


>Description:
When linking a simple pcap-using program with libpcap.a, the linker behavior
differs when using static and dynamic linking:

1)  When using -static, it links and seems to run correctly.

2)  When not using -static, it links but fails with
	ld.so: Undefined symbol "_fddipad" in tcpmon:/usr/lib/libpcap.so.0.0

3)  tcpdump declares fddipad in print-fddi.c:
	int     fddipad = FDDIPAD;      /* for proper alignment of header */

>How-To-Repeat:
#include <sys/types.h>
#include <sys/socket.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <err.h>
#include <pcap.h>

int
main(int argc, char **argv)
{
  pcap_t *pc;
  char   *dev;
  char   errbuf[10240];

  dev = pcap_lookupdev(errbuf);
  if (dev == NULL)
    errx(1, "Cannot open device: %s\n", errbuf);
}

>Fix:
Unknown, but IMHO:

	o The linker should notice and complain about the undefined
	  extern "fddipad" in _both_ cases, at link time.
	o fddipad should be moved to libpcap rather than in tcpdump.
>Audit-Trail:
>Unformatted: