网络监控
绝大多数的现代操作系统都提供了对底层网络数据包捕获的机制，在捕获机制之上可以建立网络监控（NetworkMonitoring）应用软件。网络监控也常简称为sniffer,其最初的目的在于对网络通信情况进行监控，以对网络的一些异常情况进行调试处理。但随着互连网的快速普及和网络攻击行为的频繁出现，保护网络的运行安全也成为监控软件的另一个重要目的。例如，网络监控在路由器，防火墙、入侵检查等方面使用也很广泛。除此而外，它也是一种比较有效的黑客手段，例如，美国政府安全部门的"肉食动物"计划。

包捕获机制
从广义的角度上看，一个包捕获机制包含三个主要部分：最底层是针对特定操作系统的包捕获机制，最高层是针对用户程序的接口，第三部分是包过滤机制。

不同的操作系统实现的底层包捕获机制可能是不一样的，但从形式上看大同小异。数据包常规的传输路径依次为网卡、设备驱动层、数据链路层、IP层、传输层、最后到达应用程序。而包捕获机制是在数据链路层增加一个旁路处理，对发送和接收到的数据包做过滤/缓冲等相关处理，最后直接传递到应用程序。值得注意的是，包捕获机制并不影响操作系统对数据包的网络栈处理。对用户程序而言，包捕获机制提供了一个统一的接口，使用户程序只需要简单的调用若干函数就能获得所期望的数据包。这样一来，针对特定操作系统的捕获机制对用户透明，使用户程序有比较好的可移植性。包过滤机制是对所捕获到的数据包根据用户的要求进行筛选，最终只把满足过滤条件的数据包传递给用户程序。

Libpcap 应用程序框架
Libpcap提供了系统独立的用户级别网络数据包捕获接口，并充分考虑到应用程序的可移植性。Libpcap 可以在绝大多数类 unix 平台下工作，参考资料A 中是对基于 libpcap 的网络应用程序的一个详细列表。在 windows 平台下，一个与libpcap 很类似的函数包 winpcap提供捕获功能，其官方网站是http://winpcap.polito.it/。

Libpcap 软件包可从 http://www.tcpdump.org/ 下载，然后依此执行下列三条命令即可安装，但如果希望 libpcap 能在 linux 上正常工作，则必须使内核支持"packet"协议，也即在编译内核时打开配置选项 CONFIG_PACKET(选项缺省为打开)。

./configure
./make
./make install

libpcap 源代码由 20 多个 C 文件构成，但在Linux 系统下并不是所有文件都用到。可以通过查看命令 make 的输出了解实际所用的文件。本文所针对的libpcap 版本号为0.8.3，网络类型为常规以太网。Libpcap 应用程序从形式上看很简单，下面是一个简单的程序框架：

char * device; /* 用来捕获数据包的网络接口的名称 */
pcap_t * p; /* 捕获数据包句柄，最重要的数据结构 */
struct bpf_program fcode; /* BPF 过滤代码结构 */

/* 第一步：查找可以捕获数据包的设备 */
device = pcap_lookupdev(errbuf)；

/* 第二步：创建捕获句柄，准备进行捕获 */
p = pcap_open_live(device, 8000, 1, 500, errbuf)；

/* 第三步：如果用户设置了过滤条件，则编译和安装过滤代码 */
pcap_compile(p, &fcode, filter_string, 0, netmask)；
pcap_setfilter(p, &fcode)；

/* 第四步：进入（死）循环，反复捕获数据包 */
for( ; ; )
{
while((ptr = (char *)(pcap_next(p, &hdr))) == NULL);

/* 第五步：对捕获的数据进行类型转换，转化成以太数据包类型 */
eth = (struct libnet_ethernet_hdr *)ptr;

/* 第六步：对以太头部进行分析，判断所包含的数据包类型，做进一步的处理 */
if(eth->ether_type == ntohs(ETHERTYPE_IP)) 
…………
if(eth->ether_type == ntohs(ETHERTYPE_ARP)) 
…………
}

/* 最后一步：关闭捕获句柄,一个简单技巧是在程序初始化时增加信号处理函数，
以便在程序退出前执行本条代码 */
pcap_close(p)；

检查网络设备
libpcap程序的第一步通常是在系统中找到合适的网络接口设备。网络接口在Linux网络体系中是一个很重要的概念，它是对具体网络硬件设备的一个抽象，在它的下面是具体的网卡驱动程序，而其上则是网络协议层。Linux中最常见的接口设备名 eth0 和 lo。Lo 称为回路设备，是一种逻辑意义上的设备,其主要目的是为了调试网络程序之间的通讯功能。eth0对应了实际的物理网卡，在真实网络环境下，数据包的发送和接收都要通过 eht0。如果计算机有多个网卡，则还可以有更多的网络接口，如eth1,eth2 等等。调用命令 ifconfig 可以列出当前所有活跃的接口及相关信息，注意对 eth0 的描述中既有物理网卡的 MAC地址，也有网络协议的 IP 地址。查看文件 /proc/net/dev 也可获得接口信息。

Libpcap 中检查网络设备中主要使用到的函数关系如下图：

libpcap调用 pcap_lookupdev() 函数获得可用网络接口的设备名。首先利用函数 getifaddrs()获得所有网络接口的地址，以及对应的网络掩码、广播地址、目标地址等相关信息，再利用add_addr_to_iflist()、add_or_find_if()、get_instance() 把网络接口的信息增加到结构链表pcap_if 中，最后从链表中提取第一个接口作为捕获设备。其中 get_instanced()的功能是从设备名开始,找第一个是数字的字符,做为接口的实例号。网络接口的设备号越小，则排在链表的越前面，因此，通常函数最后返回的设备名为eth0。虽然 libpcap 可以工作在回路接口上，但显然 libpcap开发者认为捕获本机进程之间的数据包没有多大意义。在检查网络设备操作中，主要用到的数据结构和代码如下：

/* libpcap 自定义的接口信息链表 [pcap.h] */
struct pcap_if 
{
struct pcap_if *next; 
char *name; /* 接口设备名 */
char *description; /* 接口描述 */

/*接口的 IP 地址, 地址掩码, 广播地址,目的地址 */
struct pcap_addr addresses; 
bpf_u_int32 flags;/* 接口的参数 */
};

char * pcap_lookupdev(register char * errbuf)
{
pcap_if_t *alldevs;
……
pcap_findalldevs(&alldevs, errbuf)；
……
strlcpy(device, alldevs->name, sizeof(device));
}

打开网络设备
当设备找到后，下一步工作就是打开设备以准备捕获数据包。Libpcap 的包捕获是建立在具体的操作系统所提供的捕获机制上，而 Linux 系统随着版本的不同，所支持的捕获机制也有所不同。

2.0及以前的内核版本使用一个特殊的 socket 类型 SOCK_PACKET，调用形式是 socket(PF_INET,SOCK_PACKET, int protocol)，但 Linux 内核开发者明确指出这种方式已过时。Linux 在 2.2及以后的版本中提供了一种新的协议簇 PF_PACKET 来实现捕获机制。PF_PACKET 的调用形式为 socket(PF_PACKET,int socket_type, int protocol)，其中 socket 类型可以是 SOCK_RAW 和SOCK_DGRAM。SOCK_RAW 类型使得数据包从数据链路层取得后，不做任何修改直接传递给用户程序，而 SOCK_DRRAM则要对数据包进行加工(cooked)，把数据包的数据链路层头部去掉，而使用一个通用结构 sockaddr_ll 来保存链路信息。

使用 2.0 版本内核捕获数据包存在多个问题：首先，SOCK_PACKET 方式使用结构 sockaddr_pkt来保存数据链路层信息，但该结构缺乏包类型信息；其次，如果参数 MSG_TRUNC 传递给读包函数recvmsg()、recv()、recvfrom()等，则函数返回的数据包长度是实际读到的包数据长度，而不是数据包真正的长度。Libpcap 的开发者在源代码中明确建议不使用 2.0版本进行捕获。

相对 2.0 版本 SOCK_PACKET 方式，2.2 版本的 PF_PACKET方式则不存在上述两个问题。在实际应用中，用户程序显然希望直接得到"原始"的数据包，因此使用 SOCK_RAW类型最好。但在下面两种情况下，libpcap 不得不使用 SOCK_DGRAM类型，从而也必须为数据包合成一个"伪"链路层头部（sockaddr_ll）。

• 某些类型的设备数据链路层头部不可用：例如 Linux 内核的 PPP 协议实现代码对 PPP 数据包头部的支持不可靠。
• 在捕获设备为"any"时：所有设备意味着 libpcap 对所有接口进行捕获，为了使包过滤机制能在所有类型的数据包上正常工作,要求所有的数据包有相同的数据链路头部。

打开网络设备的主函数是 pcap_open_live()[pcap-linux.c]，其任务就是通过给定的接口设备名，获得一个捕获句柄：结构pcap_t。pcap_t 是大多数 libpcap 函数都要用到的参数，其中最重要的属性则是上面讨论到的三种 socket方式中的某一种。首先我们看看 pcap_t 的具体构成。

struct pcap [pcap-int.h]
{ 
int fd; /* 文件描述字，实际就是 socket */

/* 在 socket 上，可以使用 select() 和 poll() 等 I/O 复用类型函数 */
int selectable_fd; 

int snapshot; /* 用户期望的捕获数据包最大长度 */
int linktype; /* 设备类型 */
int tzoff;/* 时区位置，实际上没有被使用 */
int offset;/* 边界对齐偏移量 */

int break_loop; /* 强制从读数据包循环中跳出的标志 */

struct pcap_sf sf; /* 数据包保存到文件的相关配置数据结构 */
struct pcap_md md; /* 具体描述如下 */

int bufsize; /* 读缓冲区的长度 */
u_char buffer; /* 读缓冲区指针 */
u_char *bp;
int cc;
u_char *pkt;

/* 相关抽象操作的函数指针，最终指向特定操作系统的处理函数 */
int(*read_op)(pcap_t *, int cnt, pcap_handler, u_char *);
int(*setfilter_op)(pcap_t *, struct bpf_program *);
int(*set_datalink_op)(pcap_t *, int);
int(*getnonblock_op)(pcap_t *, char *);
int(*setnonblock_op)(pcap_t *, int, char *);
int(*stats_op)(pcap_t *, struct pcap_stat *);
void (*close_op)(pcap_t *);

/*如果 BPF 过滤代码不能在内核中执行,则将其保存并在用户空间执行 */
struct bpf_program fcode; 

/* 函数调用出错信息缓冲区 */
char errbuf[PCAP_ERRBUF_SIZE + 1]; 

/* 当前设备支持的、可更改的数据链路类型的个数 */
int dlt_count;
/* 可更改的数据链路类型号链表，在 linux 下没有使用 */
int *dlt_list;

/* 数据包自定义头部，对数据包捕获时间、捕获长度、真实长度进行描述 [pcap.h] */
struct pcap_pkthdr pcap_header;
};

/* 包含了捕获句柄的接口、状态、过滤信息  [pcap-int.h] */
struct pcap_md {
/* 捕获状态结构  [pcap.h] */
struct pcap_stat stat;  

int use_bpf; /* 如果为1，则代表使用内核过滤*/ 
u_longTotPkts; 
u_longTotAccepted; /* 被接收数据包数目 */ 
u_longTotDrops;/* 被丢弃数据包数目 */ 
longTotMissed;/* 在过滤进行时被接口丢弃的数据包数目 */
longOrigMissed; /*在过滤进行前被接口丢弃的数据包数目*/
#ifdef linux
intsock_packet; /* 如果为 1，则代表使用 2.0 内核的 SOCK_PACKET 模式 */
inttimeout;/* pcap_open_live() 函数超时返回时间*/ 
intclear_promisc; /* 关闭时设置接口为非混杂模式 */ 
intcooked;/* 使用 SOCK_DGRAM 类型 */
intlo_ifindex;/* 回路设备索引号 */
char *device;/* 接口设备名称 */ 

/* 以混杂模式打开 SOCK_PACKET 类型 socket 的 pcap_t 链表*/
struct pcap *next;
#endif
};

函数 pcap_open_live() 的调用形式是pcap_t * pcap_open_live(const char *device, int snaplen, int promisc,int to_ms, char *ebuf)，其中如果 device 为 NULL 或"any"，则对所有接口捕获，snaplen代表用户期望的捕获数据包最大长度，promisc代表设置接口为混杂模式（捕获所有到达接口的数据包，但只有在设备给定的情况下有意义），to_ms代表函数超时返回的时间。本函数的代码比较简单，其执行步骤如下：

• 为结构 pcap_t 分配空间并根据函数入参对其部分属性进行初试化。
• 分别利用函数 live_open_new() 或 live_open_old() 尝试创建 PF_PACKET 方式或 SOCK_PACKET 方式的 socket，注意函数名中一个为"new"，另一个为"old"。
• 根据 socket 的方式，设置捕获句柄的读缓冲区长度，并分配空间。
• 为捕获句柄 pcap_t 设置 linux 系统下的特定函数，其中最重要的是读数据包函数和设置过滤器函数。（注意到这种从抽象模式到具体模式的设计思想在 linux 源代码中也多次出现，如 VFS 文件系统）
  handle->read_op = pcap_read_linux；handle->setfilter_op = pcap_setfilter_linux；

下面我们依次分析 2.2 和 2.0 内核版本下的 socket 创建函数。

static int
live_open_new(pcap_t *handle, const char *device, int promisc,
   int to_ms, char *ebuf)
{
/* 如果设备给定,则打开一个 RAW 类型的套接字,否则,打开 DGRAM 类型的套接字 */
sock_fd = device ?
socket(PF_PACKET, SOCK_RAW, htons(ETH_P_ALL))
      : socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL));

/* 取得回路设备接口的索引 */
handle->md.lo_ifindex = iface_get_id(sock_fd, "lo", ebuf);

/* 如果设备给定，但接口类型未知或是某些必须工作在加工模式下的特定类型，则使用加工模式 */
if (device) {
/* 取得接口的硬件类型 */
arptype = iface_get_arptype(sock_fd, device, ebuf); 

/* linux 使用 ARPHRD_xxx 标识接口的硬件类型，而 libpcap 使用DLT_xxx
来标识。本函数是对上述二者的做映射变换，设置句柄的链路层类型为
DLT_xxx，并设置句柄的偏移量为合适的值，使其与链路层头部之和为 4 的倍数，目的是边界对齐 */
map_arphrd_to_dlt(handle, arptype, 1);

/* 如果接口是前面谈到的不支持链路层头部的类型，则退而求其次，使用 SOCK_DGRAM 模式 */
if (handle->linktype == xxx) 
{
close(sock_fd)；
sock_fd = socket(PF_PACKET, SOCK_DGRAM, htons(ETH_P_ALL));
}

/* 获得给定的设备名的索引 */
device_id = iface_get_id(sock_fd, device, ebuf);

/* 把套接字和给定的设备绑定，意味着只从给定的设备上捕获数据包 */
iface_bind(sock_fd, device_id, ebuf)；

} else { /* 现在是加工模式 */
handle->md.cooked = 1;
/* 数据包链路层头部为结构 sockaddr_ll， SLL 大概是结构名称的简写形式 */
handle->linktype = DLT_LINUX_SLL;
device_id = -1;
}

/* 设置给定设备为混杂模式 */
if (device && promisc) 
{
memset(&mr, 0, sizeof(mr));
mr.mr_ifindex = device_id;
mr.mr_type = PACKET_MR_PROMISC;
setsockopt(sock_fd, SOL_PACKET, PACKET_ADD_MEMBERSHIP, 
&mr, sizeof(mr))；
}

/* 最后把创建的 socket 保存在句柄 pcap_t 中 */
handle->fd = sock_fd;
}

/* 2.0 内核下函数要简单的多，因为只有唯一的一种 socket 方式 */
static int
live_open_old(pcap_t *handle, const char *device, int promisc,
      int to_ms, char *ebuf)
{
/* 首先创建一个SOCK_PACKET类型的 socket */
handle->fd = socket(PF_INET, SOCK_PACKET, htons(ETH_P_ALL));

/* 2.0 内核下，不支持捕获所有接口，设备必须给定 */
if (!device) {
strncpy(ebuf, "pcap_open_live: The \"any\" device isn't supported on 2.0[.x]-kernel systems", PCAP_ERRBUF_SIZE);
break;
}

/* 把 socket 和给定的设备绑定 */
iface_bind_old(handle->fd, device, ebuf)；

/*以下的处理和 2.2 版本下的相似，有所区别的是如果接口链路层类型未知，则 libpcap 直接退出 */
 
arptype = iface_get_arptype(handle->fd, device, ebuf);
map_arphrd_to_dlt(handle, arptype, 0);
if (handle->linktype == -1) {
snprintf(ebuf, PCAP_ERRBUF_SIZE, "unknown arptype %d", arptype);
break;
}

/* 设置给定设备为混杂模式 */
if (promisc) {
memset(&ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, device, sizeof(ifr.ifr_name));
ioctl(handle->fd, SIOCGIFFLAGS, &ifr)；
ifr.ifr_flags |= IFF_PROMISC;
ioctl(handle->fd, SIOCSIFFLAGS, &ifr)；
}
}

比较上面两个函数的代码，还有两个细节上的区别。首先是 socket 与接口绑定所使用的结构：老式的绑定使用了结构 sockaddr，而新式的则使用了 2.2 内核中定义的通用链路头部层结构 sockaddr_ll。

iface_bind_old(int fd, const char *device, char *ebuf)
{
struct sockaddrsaddr;
memset(&saddr, 0, sizeof(saddr));
strncpy(saddr.sa_data, device, sizeof(saddr.sa_data));
bind(fd, &saddr, sizeof(saddr))；
}

iface_bind(int fd, int ifindex, char *ebuf)
{
struct sockaddr_llsll;
memset(&sll, 0, sizeof(sll));
sll.sll_family = AF_PACKET;
sll.sll_ifindex = ifindex;
sll.sll_protocol= htons(ETH_P_ALL);
bind(fd, (struct sockaddr *) &sll, sizeof(sll)；
}

第二个是在 2.2 版本中设置设备为混杂模式时，使用了函数setsockopt()，以及新的标志 PACKET_ADD_MEMBERSHIP 和结构packet_mreq。我估计这种方式主要是希望提供一个统一的调用接口，以代替传统的（混乱的）ioctl 调用。

struct packet_mreq
{
int             mr_ifindex;    /* 接口索引号 */
unsigned short  mr_type;       /* 要执行的操作(号) */
unsigned short  mr_alen;       /* 地址长度 */
unsigned char   mr_address[8]; /* 物理层地址 */ 
};

用户应用程序接口
Libpcap 提供的用户程序接口比较简单，通过反复调用函数pcap_next()[pcap.c] 则可获得捕获到的数据包。下面是一些使用到的数据结构：

/* 单个数据包结构，包含数据包元信息和数据信息 */
struct singleton [pcap.c]
{
struct pcap_pkthdr hdr; /* libpcap 自定义数据包头部 */
const u_char * pkt; /* 指向捕获到的网络数据 */
};

/* 自定义头部在把数据包保存到文件中也被使用 */
struct pcap_pkthdr 
{
struct timeval ts; /* 捕获时间戳 */ 
bpf_u_int32 caplen; /* 捕获到数据包的长度 */
bpf_u_int32 len; /* 数据包的真正长度 */
}

/* 函数 pcap_next() 实际上是对函数 pcap_dispatch()[pcap.c] 的一个包装 */
const u_char * pcap_next(pcap_t *p, struct pcap_pkthdr *h)
{
struct singleton s;
s.hdr = h;

/*入参"1"代表收到1个数据包就返回；回调函数 pcap_oneshot() 是对结构 singleton 的属性赋值 */
if (pcap_dispatch(p, 1, pcap_oneshot, (u_char*)&s) <= 0)
return (0);
return (s.pkt); /* 返回数据包缓冲区的指针 */
}

pcap_dispatch() 简单的调用捕获句柄pcap_t 中定义的特定操作系统的读数据函数：return p->read_op(p, cnt, callback, user)。在linux 系统下，对应的读函数为 pcap_read_linux()（在创建捕获句柄时已定义[pcap-linux.c]），而pcap_read_linux() 则是直接调用pcap_read_packet()([pcap-linux.c])。

pcap_read_packet() 的中心任务是利用了recvfrom() 从已创建的 socket 上读数据包数据，但是考虑到 socket可能为前面讨论到的三种方式中的某一种，因此对数据缓冲区的结构有相应的处理，主要表现在加工模式下对伪链路层头部的合成。具体代码分析如下：

static int
pcap_read_packet(pcap_t *handle, pcap_handler callback, u_char *userdata)
{
/* 数据包缓冲区指针 */
u_char * bp;

/* bp 与捕获句柄 pcap_t 中 handle->buffer
之间的偏移量，其目的是为在加工模式捕获情况下，为合成的伪数据链路层头部留出空间 */
int offset;

/* PACKET_SOCKET 方式下，recvfrom() 返回 scokaddr_ll 类型，而在SOCK_PACKET 方式下，
返回 sockaddr 类型 */
#ifdef HAVE_PF_PACKET_SOCKETS 
struct sockaddr_llfrom;
struct sll_header* hdrp;
#else
struct sockaddrfrom;
#endif

socklen_tfromlen;
intpacket_len, caplen;

/* libpcap 自定义的头部 */
struct pcap_pkthdrpcap_header;

#ifdef HAVE_PF_PACKET_SOCKETS
/* 如果是加工模式，则为合成的链路层头部留出空间 */
if (handle->md.cooked)
offset = SLL_HDR_LEN;

/* 其它两中方式下，链路层头部不做修改的被返回，不需要留空间 */
else
offset = 0;
#else
offset = 0;
#endif

bp = handle->buffer + handle->offset;

/* 从内核中接收一个数据包，注意函数入参中对 bp 的位置进行修正 */
packet_len = recvfrom( handle->fd, bp + offset,
handle->bufsize - offset, MSG_TRUNC,
(struct sockaddr *) &from, &fromlen);

#ifdef HAVE_PF_PACKET_SOCKETS

/* 如果是回路设备,则只捕获接收的数据包，而拒绝发送的数据包。显然，我们只能在 PF_PACKET
方式下这样做,因为 SOCK_PACKET 方式下返回的链路层地址类型为
sockaddr_pkt，缺少了判断数据包类型的信息。*/
if (!handle->md.sock_packet &&
from.sll_ifindex == handle->md.lo_ifindex &&
from.sll_pkttype == PACKET_OUTGOING)
return 0;
#endif

#ifdef HAVE_PF_PACKET_SOCKETS
/* 如果是加工模式，则合成伪链路层头部 */
if (handle->md.cooked) {
/* 首先修正捕包数据的长度，加上链路层头部的长度 */
packet_len += SLL_HDR_LEN;
hdrp = (struct sll_header *)bp;

/* 以下的代码分别对伪链路层头部的数据赋值 */
hdrp->sll_pkttype = xxx;
hdrp->sll_hatype = htons(from.sll_hatype);
hdrp->sll_halen = htons(from.sll_halen);
memcpy(hdrp->sll_addr, from.sll_addr, 
(from.sll_halen > SLL_ADDRLEN) ? 
SLL_ADDRLEN : from.sll_halen);
hdrp->sll_protocol = from.sll_protocol;
}
#endif

/* 修正捕获的数据包的长度，根据前面的讨论，SOCK_PACKET 方式下长度可能是不准确的 */
caplen = packet_len;
if (caplen > handle->snapshot)
caplen = handle->snapshot;

/* 如果没有使用内核级的包过滤,则在用户空间进行过滤*/
if (!handle->md.use_bpf && handle->fcode.bf_insns) {
if (bpf_filter(handle->fcode.bf_insns, bp,
packet_len, caplen) == 0)
{
/* 没有通过过滤，数据包被丢弃 */
return 0;
}
}

/* 填充 libpcap 自定义数据包头部数据：捕获时间,捕获的长度,真实的长度 */
ioctl(handle->fd, SIOCGSTAMP, &pcap_header.ts)；
pcap_header.caplen= caplen;
pcap_header.len= packet_len;

/* 累加捕获数据包数目，注意到在不同内核/捕获方式情况下数目可能不准确 */
handle->md.stat.ps_recv++;

/* 调用用户定义的回调函数 */
callback(userdata, &pcap_header, bp);
}

数据包过滤机制
大量的网络监控程序目的不同，期望的数据包类型也不同，但绝大多数情况都都只需要所有数据包的一（小）部分。例如：对邮件系统进行监控可能只需要端口号为25（smtp）和 110（pop3) 的 TCP 数据包，对 DNS 系统进行监控就只需要端口号为 53 的 UDP数据包。包过滤机制的引入就是为了解决上述问题，用户程序只需简单的设置一系列过滤条件，最终便能获得满足条件的数据包。包过滤操作可以在用户空间执行，也可以在内核空间执行，但必须注意到数据包从内核空间拷贝到用户空间的开销很大，所以如果能在内核空间进行过滤，会极大的提高捕获的效率。内核过滤的优势在低速网络下表现不明显，但在高速网络下是非常突出的。在理论研究和实际应用中，包捕获和包过滤从语意上并没有严格的区分，关键在于认识到捕获数据包必然有过滤操作。基本上可以认为，包过滤机制在包捕获机制中占中心地位。

包过滤机制实际上是针对数据包的布尔值操作函数，如果函数最终返回true，则通过过滤，反之则被丢弃。形式上包过滤由一个或多个谓词判断的并操作（AND）和或操作（OR）构成，每一个谓词判断基本上对应了数据包的协议类型或某个特定值,例如：只需要 TCP 类型且端口为 110 的数据包或 ARP类型的数据包。包过滤机制在具体的实现上与数据包的协议类型并无多少关系，它只是把数据包简单的看成一个字节数组，而谓词判断会根据具体的协议映射到数组特定位置的值。如判断ARP类型数据包，只需要判断数组中第 13、14 个字节（以太头中的数据包类型）是否为0X0806。从理论研究的意思上看，包过滤机制是一个数学问题，或者说是一个算法问题，其中心任务是如何使用最少的判断操作、最少的时间完成过滤处理，提高过滤效率。

BPF
Libpcap重点使用 BPF（BSD Packet Filter）包过滤机制，BPF 于 1992年被设计出来，其设计目的主要是解决当时已存在的过滤机制效率低下的问题。BPF的工作步骤如下：当一个数据包到达网络接口时，数据链路层的驱动会把它向系统的协议栈传送。但如果 BPF 监听接口，驱动首先调用 BPF。BPF首先进行过滤操作，然后把数据包存放在过滤器相关的缓冲区中，最后设备驱动再次获得控制。注意到BPF是先对数据包过滤再缓冲，避免了类似 sun 的NIT 过滤机制先缓冲每个数据包直到用户读数据时再过滤所造成的效率问题。参考资料D是关于 BPF 设计思想最重要的文献。

BPF的设计思想和当时的计算机硬件的发展有很大联系，相对老式的过滤方式CSPF（CMU/Stanford PacketFilter）它有两大特点。1：基于寄存器的过滤机制，而不是早期内存堆栈过滤机制，2：直接使用独立的、非共享的内存缓冲区。同时，BPF在过滤算法是也有很大进步，它使用无环控制流图（CFG control flow graph）,而不是老式的布尔表达式树（booleanexpression tree）。布尔表达式树理解上比较直观，它的每一个叶子节点即是一个谓词判断，而非叶子节点则为 AND 操作或OR操作。CSPF有三个主要的缺点。1：过滤操作使用的栈在内存中被模拟，维护栈指针需要使用若干的加/减等操作，而内存操作是现代计算机架构的主要瓶颈。2：布尔表达式树造成了不需要的重复计算。3：不能分析数据包的变长头部。BPF 使用的CFG算法实际上是一种特殊的状态机，每一节点代表了一个谓词判断，而左右边分别对应了判断失败和成功后的跳转，跳转后又是谓词判断，这样反复操作，直到到达成功或失败的终点。CFG 算法的优点在于把对数据包的分析信息直接建立在图中，从而不需要重复计算。直观的看，CFG是一种"快速的、一直向前"的算法。

过滤代码的编译
BPF对 CFG 算法的代码实现非常复杂，它使用伪机器方式。BPF 伪机器是一个轻量级的，高效的状态机，对 BPF 过滤代码进行解释处理。BPF过滤代码形式为"opcode jt jf k"，分别代表了操作码和寻址方式、判断正确的跳转、判断失败的跳转、操作使用的通用数据域。BPF过滤代码从逻辑上看很类似于汇编语言，但它实际上是机器语言，注意到上述 4 个域的数据类型都是 int 和 char型。显然，由用户来写过滤代码太过复杂，因此 libpcap 允许用户书写高层的、容易理解的过滤字符串，然后将其编译为BPF代码。

Libpcap使用了 4 个源程序gencode.c、optimize.c、grammar.c、scanner.c完成编译操作，其中前两个实现了对过滤字符串的编译和优化，后两个主要是为编译提供从协议相关过滤条件到协议无关(的字符数组)位置信息的映射，并且它们由词汇分析器生成器 flex 和 bison 生成。参考资料C 有对此两个工具的讲解。

flex -Ppcap_ -t scanner.l > $$.scanner.c; mv $$.scanner.c scanner.c
bison -y -p pcap_ -d grammar.y
mv y.tab.c grammar.c
mv y.tab.h tokdefs.h

编译过滤字符串调用了函数 pcap_compile()[getcode.c]，形式为：

int pcap_compile(pcap_t *p, struct bpf_program *program,
     char *buf, int optimize, bpf_u_int32 mask)

其中 buf 指向用户过滤字符串，编译后的 BPF 代码存在在结构 bpf_program中，标志 optimize 指示是否对 BPF 代码进行优化。

/* [pcap-bpf.h] */
struct bpf_program {
u_int bf_len; /* BPF 代码中谓词判断指令的数目 */
struct bpf_insn *bf_insns; /* 第一个谓词判断指令 */
};

/* 谓词判断指令结构，含意在前面已描述 [pcap-bpf.h] */
struct bpf_insn {
u_shortcode;
u_char jt;
u_char jf;
bpf_int32 k;
};

过滤代码的安装
前面我们曾经提到，在内核空间过滤数据包对整个捕获机制的效率是至关重要的。早期使用 SOCK_PACKET 方式的 Linux不支持内核过滤，因此过滤操作只能在用户空间执行（请参阅函数 pcap_read_packet() 代码）,在《UNIX网络编程(第一卷)》（参考资料 B）的第 26 章中对此有明确的描述。不过现在看起来情况已经发生改变，linux 在 PF_PACKET类型的 socket 上支持内核过滤。Linux 内核允许我们把一个名为 LPF(Linux Packet Filter) 的过滤器直接放到PF_PACKET 类型 socket 的处理过程中，过滤器在网卡接收中断执行后立即执行。LSF 基于 BPF机制，但两者在实现上有略微的不同。实际代码如下：

/* 在包捕获设备上附加 BPF 代码 [pcap-linux.c]*/
static int
pcap_setfilter_linux(pcap_t *handle, struct bpf_program *filter)
{
#ifdef SO_ATTACH_FILTER
struct sock_fprogfcode;
int can_filter_in_kernel;
int err = 0;
#endif

/* 检查句柄和过滤器结构的正确性 */
if (!handle)
return -1;
if (!filter) {
strncpy(handle->errbuf, "setfilter: No filter specified",
sizeof(handle->errbuf));
return -1;
}

/* 具体描述如下 */ 
if (install_bpf_program(handle, filter) < 0)
return -1;

/* 缺省情况下在用户空间运行过滤器,但如果在内核安装成功,则值为 1 */
handle->md.use_bpf = 0;


/* 尝试在内核安装过滤器 */
#ifdef SO_ATTACH_FILTER
#ifdef USHRT_MAX
if (handle->fcode.bf_len > USHRT_MAX) {
/*过滤器代码太长，内核不支持 */
fprintf(stderr, "Warning: Filter too complex for kernel\n");
fcode.filter = NULL;
can_filter_in_kernel = 0;
} else
#endif /* USHRT_MAX */
{
/* linux 内核设置过滤器时使用的数据结构是 sock_fprog，而不是 BPF 的结构 bpf_program ,因此应做结构之间的转换 */
switch (fix_program(handle, &fcode)) {

/* 严重错误，直接退出 */
case -1:
default: 
return -1;

/* 通过检查，但不能工作在内核中 */
case 0: 
can_filter_in_kernel = 0;
break;

/* BPF 可以在内核中工作 */
case 1: 
can_filter_in_kernel = 1;
break;
}
}

/* 如果可以在内核中过滤，则安装过滤器到内核中 */
if (can_filter_in_kernel) {
if ((err = set_kernel_filter(handle, &fcode)) == 0)
{
/* 安装成功 !!! */
handle->md.use_bpf = 1;
}
else if (err == -1)/* 出现非致命性错误 */
{
if (errno != ENOPROTOOPT && errno != EOPNOTSUPP) {
fprintf(stderr, "Warning: Kernel filter failed:
 %s\n",pcap_strerror(errno));
}
}
}

/* 如果不能在内核中使用过滤器，则去掉曾经可能在此 socket
上安装的内核过滤器。主要目的是为了避免存在的过滤器对数据包过滤的干扰 */
if (!handle->md.use_bpf)
reset_kernel_filter(handle);[pcap-linux.c]
#endif 
}


/* 把 BPF 代码拷贝到 pcap_t 数据结构的 fcode 上 */
int install_bpf_program(pcap_t *p, struct bpf_program *fp)
{
size_t prog_size;

/* 首先释放可能已存在的 BPF 代码 */ 
pcap_freecode(&p->fcode);

/* 计算过滤代码的长度，分配内存空间 */
prog_size = sizeof(*fp->bf_insns) * fp->bf_len;
p->fcode.bf_len = fp->bf_len;
p->fcode.bf_insns = (struct bpf_insn *)malloc(prog_size);
if (p->fcode.bf_insns == NULL) {
snprintf(p->errbuf, sizeof(p->errbuf),
"malloc: %s", pcap_strerror(errno));
return (-1);
}

/* 把过滤代码保存在捕获句柄中 */
memcpy(p->fcode.bf_insns, fp->bf_insns, prog_size);

return (0);
}

/* 在内核中安装过滤器 */
static int set_kernel_filter(pcap_t *handle, struct sock_fprog *fcode)
{
int total_filter_on = 0;
int save_mode;
int ret;
int save_errno;

/*在设置过滤器前，socket 的数据包接收队列中可能已存在若干数据包。当设置过滤器后，
这些数据包极有可能不满足过滤条件，但它们不被过滤器丢弃。
这意味着，传递到用户空间的头几个数据包不满足过滤条件。
注意到在用户空间过滤这不是问题，因为用户空间的过滤器是在包进入队列后执行的。
Libpcap 解决这个问题的方法是在设置过滤器之前，
首先读完接收队列中所有的数据包。具体步骤如下。*/
 
/*为了避免无限循环的情况发生（反复的读数据包并丢弃，但新的数据包不停的到达），首先设置一个过滤器，阻止所有的包进入 */
 
setsockopt(handle->fd, SOL_SOCKET, SO_ATTACH_FILTER,
&total_fcode, sizeof(total_fcode)；

/* 保存 socket 当前的属性 */
save_mode = fcntl(handle->fd, F_GETFL, 0);

/* 设置 socket 它为非阻塞模式 */
fcntl(handle->fd, F_SETFL, save_mode | O_NONBLOCK)；

/* 反复读队列中的数据包，直到没有数据包可读。这意味着接收队列已被清空 */
while (recv(handle->fd, &drain, sizeof drain, MSG_TRUNC) >= 0)；

/* 恢复曾保存的 socket 属性 */
fcntl(handle->fd, F_SETFL, save_mode);

/* 现在安装新的过滤器 */
setsockopt(handle->fd, SOL_SOCKET, SO_ATTACH_FILTER,
fcode, sizeof(*fcode));
}

/* 释放 socket 上可能有的内核过滤器 */
static int reset_kernel_filter(pcap_t *handle)
{
int dummy;
return setsockopt(handle->fd, SOL_SOCKET, SO_DETACH_FILTER,
&dummy, sizeof(dummy));
}

linux 在安装和卸载过滤器时都使用了函数setsockopt()，其中标志SOL_SOCKET 代表了对 socket 进行设置，而 SO_ATTACH_FILTER 和SO_DETACH_FILTER 则分别对应了安装和卸载。下面是 linux 2.4.29 版本中的相关代码：

[net/core/sock.c]
#ifdef CONFIG_FILTER
case SO_ATTACH_FILTER:
……
/* 把过滤条件结构从用户空间拷贝到内核空间 */
if (copy_from_user(&fprog, optval, sizeof(fprog)))
break;
/* 在 socket 上安装过滤器 */
ret = sk_attach_filter(&fprog, sk);
……

case SO_DETACH_FILTER:
/* 使用自旋锁锁住 socket */
spin_lock_bh(&sk->lock.slock);

filter = sk->filter;
/* 如果在 socket 上有过滤器，则简单设置为空，并释放过滤器内存 */
if (filter) {
sk->filter = NULL;
spin_unlock_bh(&sk->lock.slock);
sk_filter_release(sk, filter);
break;
}
spin_unlock_bh(&sk->lock.slock);
ret = -ENONET;
break;
#endif

上面出现的 sk_attach_filter() 定义在 net/core/filter.c，它把结构sock_fprog 转换为结构 sk_filter, 最后把此结构设置为 socket 的过滤器：sk->filter = fp。

其他代码
libpcap 还提供了其它若干函数，但基本上是提供辅助或扩展功能，重要性相对弱一点。我个人认为，函数 pcap_dump_open() 和 pcap_open_offline() 可能比较有用，使用它们能把在线的数据包写入文件并事后进行分析处理。

总结
1994年 libpcap 的第一个版本被发布，到现在已有 11 年的历史，如今libpcap 被广泛的应用在各种网络监控软件中。Libpcap最主要的优点在于平台无关性，用户程序几乎不需做任何改动就可移植到其它 unix平台上；其次，libpcap也能适应各种过滤机制，特别对BPF的支持最好。分析它的源代码，可以学习开发者优秀的设计思想和实现技巧，也能了解到（linux）操作系统的网络内核实现，对个人能力的提高有很大帮助。

参考资料
A：《Libpcap, winpcap, libdnet, and libnet applications and resources》

B：《UNIX网络编程(第一卷)》 W.Richard Stevens

C：《使用 lex 和 yacc 编译代码》 Peter Seebach

D：《The BSD Packet Filter: A New Architecture for User-level Packet Capture》 Steven McCanne and Van Jacobson

E：linux 联机帮助手册：socket(2)、socket(7)、packet等

F：《xPF Packet Filtering for Low-Cost Network Monitoring》

G：《Plab a packet capture and analysis architecture》

H：《A compiler for Packet Filters》

本文介绍了在 linux 系统中，通过 Gnu autoconf 和 automake 生成 Makefile 的方法。主要探讨了生成 Makefile 的来龙去脉及其机理，接着详细介绍了配置 Configure.in 的方法及其规则。

引子

无论是在Linux还是在Unix环境中，make都是一个非常重要的编译命令。不管是自己进行项目开发还是安装应用软件，我们都经常要用到make或 make install。利用make工具，我们可以将大型的开发项目分解成为多个更易于管理的模块，对于一个包括几百个源文件的应用程序，使用make和 makefile工具就可以轻而易举的理顺各个源文件之间纷繁复杂的相互关系。

但是如果通过查阅make的帮助文档来手工编写Makefile,对任何程序员都是一场挑战。幸而有GNU 提供的Autoconf及Automake这两套工具使得编写makefile不再是一个难题。

本文将介绍如何利用 GNU Autoconf 及 Automake 这两套工具来协助我们自动产生 Makefile文件，并且让开发出来的软件可以像大多数源码包那样，只需"./configure", "make","make install" 就可以把程序安装到系统中。

模拟需求

假设源文件按如下目录存放，如图1所示，运用autoconf和automake生成makefile文件。

假设src是我们源文件目录，include目录存放其他库的头文件，lib目录存放用到的库文件，然后开始按模块存放，每个模块都有一个对应的目录，模块下再分子模块，如apple、orange。每个子目录下又分core，include，shell三个目录，其中core和shell目录存放.c文件，include的存放.h文件，其他类似。

样例程序功能：基于多线程的数据读写保护（联系作者获取整个autoconf和automake生成的Makefile工程和源码，E-mail：normalnotebook@126.com）。

工具简介

所必须的软件：autoconf/automake/m4/perl/libtool（其中libtool非必须）。

autoconf是一个用于生成可以自动地配置软件源码包，用以适应多种UNIX类系统的shell脚本工具，其中autoconf需要用到 m4，便于生成脚本。automake是一个从Makefile.am文件自动生成Makefile.in的工具。为了生成Makefile.in，automake还需用到perl，由于automake创建的发布完全遵循GNU标准，所以在创建中不需要perl。libtool是一款方便生成各种程序库的工具。

目前automake支持三种目录层次：flat、shallow和deep。

1) flat指的是所有文件都位于同一个目录中。

就是所有源文件、头文件以及其他库文件都位于当前目录中，且没有子目录。Termutils就是这一类。

2) shallow指的是主要的源代码都储存在顶层目录，其他各个部分则储存在子目录中。

就是主要源文件在当前目录中，而其它一些实现各部分功能的源文件位于各自不同的目录。automake本身就是这一类。

3) deep指的是所有源代码都被储存在子目录中；顶层目录主要包含配置信息。

就是所有源文件及自己写的头文件位于当前目录的一个子目录中，而当前目录里没有任何源文件。 GNU cpio和GNU tar就是这一类。

flat类型是最简单的，deep类型是最复杂的。不难看出，我们的模拟需求正是基于第三类deep型，也就是说我们要做挑战性的事情：)。注：我们的测试程序是基于多线程的简单程序。

生成 Makefile 的来龙去脉

首先进入 project 目录，在该目录下运行一系列命令，创建和修改几个文件，就可以生成符合该平台的Makefile文件，操作过程如下：

1) 运行autoscan命令

2) 将configure.scan 文件重命名为configure.in，并修改configure.in文件

3) 在project目录下新建Makefile.am文件，并在core和shell目录下也新建makefile.am文件

4) 在project目录下新建NEWS、 README、 ChangeLog 、AUTHORS文件

5) 将/usr/share/automake-1.X/目录下的depcomp和complie文件拷贝到本目录下

6) 运行aclocal命令

7) 运行autoconf命令

8) 运行automake -a命令

9) 运行./confiugre脚本

可以通过图2看出产生Makefile的流程，如图所示：

Configure.in的八股文

当我们利用autoscan工具生成confiugre.scan文件时，我们需要将confiugre.scan重命名为confiugre.in文件。confiugre.in调用一系列autoconf宏来测试程序需要的或用到的特性是否存在，以及这些特性的功能。

下面我们就来目睹一下confiugre.scan的庐山真面目：

# Process this file with autoconf to produce a configure script.
            AC_PREREQ(2.59)
            AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
            AC_CONFIG_SRCDIR([config.h.in])
            AC_CONFIG_HEADER([config.h])
            # Checks for programs.
            AC_PROG_CC
            # Checks for libraries.
            # FIXME: Replace `main' with a function in `-lpthread':
            AC_CHECK_LIB([pthread], [main])
            # Checks for header files.
            # Checks for typedefs, structures, and compiler characteristics.
            # Checks for library functions.
            AC_OUTPUT
            

每个configure.scan文件都是以AC_INIT开头，以AC_OUTPUT结束。我们不难从文件中看出confiugre.in文件的一般布局：

AC_INIT
            测试程序
            测试函数库
            测试头文件
            测试类型定义
            测试结构
            测试编译器特性
            测试库函数
            测试系统调用
            AC_OUTPUT
            

上面的调用次序只是建议性质的，但我们还是强烈建议不要随意改变对宏调用的次序。

现在就开始修改该文件：

$mv configure.scan configure.in
            $vim configure.in
            

修改后的结果如下：

            #                                -*- Autoconf -*-
            # Process this file with autoconf to produce a configure script.
            AC_PREREQ(2.59)
            AC_INIT(test, 1.0, normalnotebook@126.com)
            AC_CONFIG_SRCDIR([src/ModuleA/apple/core/test.c])
            AM_CONFIG_HEADER(config.h)
            AM_INIT_AUTOMAKE(test,1.0)
            # Checks for programs.
            AC_PROG_CC
            # Checks for libraries.
            # FIXME: Replace `main' with a function in `-lpthread':
            AC_CHECK_LIB([pthread], [pthread_rwlock_init])
            AC_PROG_RANLIB
            # Checks for header files.
            # Checks for typedefs, structures, and compiler characteristics.
            # Checks for library functions.
            AC_OUTPUT([Makefile
            src/lib/Makefile
            src/ModuleA/apple/core/Makefile
            src/ModuleA/apple/shell/Makefile
            ])
            

其中要将AC_CONFIG_HEADER([config.h])修改为：AM_CONFIG_HEADER(config.h), 并加入AM_INIT_AUTOMAKE(test,1.0)。由于我们的测试程序是基于多线程的程序，所以要加入AC_PROG_RANLIB，不然运行automake命令时会出错。在AC_OUTPUT输入要创建的Makefile文件名。

由于我们在程序中使用了读写锁，所以需要对库文件进行检查，即AC_CHECK_LIB([pthread], [main])，该宏的含义如下：

其中，LIBS是link的一个选项，详细请参看后续的Makefile文件。由于我们在程序中使用了读写锁，所以我们测试pthread库中是否存在pthread_rwlock_init函数。

由于我们是基于deep类型来创建makefile文件，所以我们需要在四处创建Makefile文件。即：project目录下，lib目录下，core和shell目录下。

Autoconf提供了很多内置宏来做相关的检测，限于篇幅关系，我们在这里对其他宏不做详细的解释，具体请参看参考文献1和参考文献2，也可参看autoconf信息页。

实战Makefile.am

Makefile.am是一种比Makefile更高层次的规则。只需指定要生成什么目标，它由什么源文件生成，要安装到什么目录等构成。

表一列出了可执行文件、静态库、头文件和数据文件，四种书写Makefile.am文件个一般格式。

对于可执行文件和静态库类型，如果只想编译，不想安装到系统中，可以用noinst_PROGRAMS代替bin_PROGRAMS，noinst_LIBRARIES代替lib_LIBRARIES。

Makefile.am还提供了一些全局变量供所有的目标体使用：

在Makefile.am中尽量使用相对路径，系统预定义了两个基本路径：

在上文中我们提到过安装路径，automake设置了默认的安装路径：

1) 标准安装路径

默认安装路径为：$(prefix) = /usr/local，可以通过./configure --prefix=<new_path>的方法来覆盖。

其它的预定义目录还包括：bindir = $(prefix)/bin, libdir = $(prefix)/lib, datadir = $(prefix)/share, sysconfdir = $(prefix)/etc等等。

2) 定义一个新的安装路径

比如test, 可定义testdir = $(prefix)/test, 然后test_DATA =test1 test2，则test1，test2会作为数据文件安装到$(prefix)/ /test目录下。

我们首先需要在工程顶层目录下（即project/）创建一个Makefile.am来指明包含的子目录：

SUBDIRS=src/lib src/ModuleA/apple/shell src/ModuleA/apple/core
            CURRENTPATH=$(shell /bin/pwd)
            INCLUDES=-I$(CURRENTPATH)/src/include -I$(CURRENTPATH)/src/ModuleA/apple/include
            export INCLUDES
            

由于每个源文件都会用到相同的头文件，所以我们在最顶层的Makefile.am中包含了编译源文件时所用到的头文件，并导出，见蓝色部分代码。

我们将lib目录下的swap.c文件编译成libswap.a文件，被apple/shell/apple.c文件调用，那么lib目录下的Makefile.am如下所示：

noinst_LIBRARIES=libswap.a
            libswap_a_SOURCES=swap.c
            INCLUDES=-I$(top_srcdir)/src/includ
            

细心的读者可能就会问：怎么表1中给出的是bin_LIBRARIES，而这里是noinst_LIBRARIES？这是因为如果只想编译，而不想安装到系统中，就用noinst_LIBRARIES代替bin_LIBRARIES，对于可执行文件就用noinst_PROGRAMS代替bin_PROGRAMS。对于安装的情况，库将会安装到$(prefix)/lib目录下，可执行文件将会安装到${prefix}/bin。如果想安装该库，则Makefile.am示例如下：

bin_LIBRARIES=libswap.a
            libswap_a_SOURCES=swap.c
            INCLUDES=-I$(top_srcdir)/src/include
            swapincludedir=$(includedir)/swap
            swapinclude_HEADERS=$(top_srcdir)/src/include/swap.h
            

最后两行的意思是将swap.h安装到${prefix}/include /swap目录下。

接下来，对于可执行文件类型的情况，我们将讨论如何写Makefile.am？对于编译apple/core目录下的文件，我们写成的Makefile.am如下所示：

noinst_PROGRAMS=test
            test_SOURCES=test.c
            test_LDADD=$(top_srcdir)/src/ModuleA/apple/shell/apple.o $(top_srcdir)/src/lib/libswap.a
            test_LDFLAGS=-D_GNU_SOURCE
            DEFS+=-D_GNU_SOURCE
            #LIBS=-lpthread
            

由于我们的test.c文件在链接时，需要apple.o和libswap.a文件，所以我们需要在test_LDADD中包含这两个文件。对于Linux下的信号量/读写锁文件进行编译，需要在编译选项中指明-D_GNU_SOURCE。所以在test_LDFLAGS中指明。而test_LDFLAGS只是链接时的选项，编译时同样需要指明该选项，所以需要DEFS来指明编译选项，由于DEFS已经有初始值，所以这里用+=的形式指明。从这里可以看出，Makefile.am中的语法与Makefile的语法一致，也可以采用条件表达式。如果你的程序还包含其他的库，除了用AC_CHECK_LIB宏来指明外，还可以用LIBS来指明。

如果你只想编译某一个文件，那么Makefile.am如何写呢？这个文件也很简单，写法跟可执行文件的差不多，如下例所示：

noinst_PROGRAMS=apple
            apple_SOURCES=apple.c
            DEFS+=-D_GNU_SOURCE
            

我们这里只是欺骗automake，假装要生成apple文件，让它为我们生成依赖关系和执行命令。所以当你运行完automake命令后，然后修改apple/shell/下的Makefile.in文件，直接将LINK语句删除，即：

…….
            clean-noinstPROGRAMS:
            -test -z "$(noinst_PROGRAMS)" || rm -f $(noinst_PROGRAMS)
            apple$(EXEEXT): $(apple_OBJECTS) $(apple_DEPENDENCIES)
            @rm -f apple$(EXEEXT)
            #$(LINK) $(apple_LDFLAGS) $(apple_OBJECTS) $(apple_LDADD) $(LIBS)
            …….
            

通过上述处理，就可以达到我们的目的。从图1中不难看出为什么要修改Makefile.in的原因，而不是修改其他的文件。

First make sure you remove all the qt3 dev tools so that your program isn’t compiled using qt3. It is safe and even recommended to leave the qt3 libraries installed since they may be required for other packages.

$ sudo apt-get remove qt3-dev-tools

Install the qt4 libraries and tools:

$ sudo apt-get install libqt4-core libqt4-gui libqt4-sql
$ sudo apt-get install libqt4-qt3support libqt4-dev qt4-dev-tools

If you’re a developer, you’ll want the gui tools that make development much easier.

$ sudo apt-get install qt4-designer qt4-qtconfig qt4-doc

This will install designer, assistant, and qtconfig.

Now that all the packages are installed, you should be able to compile programs. Many times the program you want to download will reside in a repository (usually CVS or Subversion) so you’ll need to install these packages.

$ sudo apt-get install subversion cvs

Download a program and try it out (or use the program you were having trouble with that caused you to come here).

$ svn co http://svn.jasonandshawnda.com/CulinaryManagement

Compile the program:

$ cd CulinaryManagement
$ qmake
$ make

QObject::connect() is perhaps the most central feature of Qt. Note that connect() is a static function in QObject. Do not confuse it with the connect() function in the Berkeley socket library.

This connect() call establishes a one-way connection between two Qt objects (objects that inherit QObject, directly or indirectly). Every Qt object can have both signals (to send messages) and slots (to receive messages). All widgets are Qt objects, since they inherit QWidget, which in turn inherits QObject.

###############################################################################

#

# Generic Makefile for C/C++ Program

#

# Author: whyglinux (whyglinux AT hotmail DOT com)

# Date:   2006/03/04



# Description:

# The makefile searches in <SRCDIRS> directories for the source files

# with extensions specified in <SOURCE_EXT>, then compiles the sources

# and finally produces the <PROGRAM>, the executable file, by linking

# the objectives.



# Usage:

#   $ make           compile and link the program.

#   $ make objs      compile only (no linking. Rarely used).

#   $ make clean     clean the objectives and dependencies.

#   $ make cleanall  clean the objectives, dependencies and executable.

#   $ make rebuild   rebuild the program. The same as make clean && make all.

#==============================================================================



## Customizing Section: adjust the following if necessary.

##=============================================================================



# The executable file name.

# It must be specified.

# PROGRAM   := a.out    # the executable name

PROGRAM   :=



# The directories in which source files reside.

# At least one path should be specified.

# SRCDIRS   := .        # current directory

SRCDIRS   :=



# The source file types (headers excluded).

# At least one type should be specified.

# The valid suffixes are among of .c, .C, .cc, .cpp, .CPP, .c++, .cp, or .cxx.

# SRCEXTS   := .c      # C program

# SRCEXTS   := .cpp    # C++ program

# SRCEXTS   := .c .cpp # C/C++ program

SRCEXTS   :=



# The flags used by the cpp (man cpp for more).

# CPPFLAGS  := -Wall -Werror # show all warnings and take them as errors

CPPFLAGS  :=



# The compiling flags used only for C.

# If it is a C++ program, no need to set these flags.

# If it is a C and C++ merging program, set these flags for the C parts.

CFLAGS    :=

CFLAGS    +=



# The compiling flags used only for C++.

# If it is a C program, no need to set these flags.

# If it is a C and C++ merging program, set these flags for the C++ parts.

CXXFLAGS  :=

CXXFLAGS  +=



# The library and the link options ( C and C++ common).

LDFLAGS   :=

LDFLAGS   +=



## Implict Section: change the following only when necessary.

##=============================================================================

# The C program compiler. Uncomment it to specify yours explicitly.

#CC      = gcc



# The C++ program compiler. Uncomment it to specify yours explicitly.

#CXX     = g++



# Uncomment the 2 lines to compile C programs as C++ ones.

#CC      = $(CXX)

#CFLAGS  = $(CXXFLAGS)



# The command used to delete file.

#RM        = rm -f



## Stable Section: usually no need to be changed. But you can add more.

##=============================================================================

SHELL   = /bin/sh

SOURCES = $(foreach d,$(SRCDIRS),$(wildcard $(addprefix $(d)/*,$(SRCEXTS))))

OBJS    = $(foreach x,$(SRCEXTS), \

      $(patsubst %$(x),%.o,$(filter %$(x),$(SOURCES))))

DEPS    = $(patsubst %.o,%.d,$(OBJS))



.PHONY : all objs clean cleanall rebuild



all : $(PROGRAM)



# Rules for creating the dependency files (.d).

#---------------------------------------------------

%.d : %.c

	@$(CC) -MM -MD $(CFLAGS) $<



%.d : %.C

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.cc

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.cpp

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.CPP

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.c++

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.cp

	@$(CC) -MM -MD $(CXXFLAGS) $<



%.d : %.cxx

	@$(CC) -MM -MD $(CXXFLAGS) $<



# Rules for producing the objects.

#---------------------------------------------------

objs : $(OBJS)



%.o : %.c

	$(CC) -c $(CPPFLAGS) $(CFLAGS) $<



%.o : %.C

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.cc

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.cpp

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.CPP

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.c++

	$(CXX -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.cp

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



%.o : %.cxx

	$(CXX) -c $(CPPFLAGS) $(CXXFLAGS) $<



# Rules for producing the executable.

#----------------------------------------------

$(PROGRAM) : $(OBJS)

ifeq ($(strip $(SRCEXTS)), .c)  # C file

	$(CC) -o $(PROGRAM) $(OBJS) $(LDFLAGS)

else                            # C++ file

	$(CXX) -o $(PROGRAM) $(OBJS) $(LDFLAGS)

endif



-include $(DEPS)



rebuild: clean all



clean :

	@$(RM) *.o *.d



cleanall: clean

	@$(RM) $(PROGRAM) $(PROGRAM).exe



### End of the Makefile ##  Suggestions are welcome  ## All rights reserved ###

###############################################################################

/* File name: hello.h

 * C header file

 */



#ifndef HELLO_H

#define HELLO_H



#ifdef __cplusplus

extern "C" {

#endif



  void print_hello();



#ifdef __cplusplus

}

#endif



#endif

/* File name: hello.c

 * C source file.

 */

#include "hello.h"

#include <stdio.h>



void print_hello()

{

  puts( "Hello, world!" );

}

/* File name: main.cxx

 * C++ source file.

 */

#include "hello.h"



int main()

{

  print_hello();



  return 0;

}

PROGRAM   := hello      # 设置运行程序名

SRCDIRS   := .          # 源程序位于当前目录下

SRCEXTS   := .c .cxx    # 源程序文件有 .c 和 .cxx 两种类型

CFLAGS    := -g         # 为 C 目标程序包含 GDB 可用的调试信息

CXXFLAGS  := -g         # 为 C++ 目标程序包含 GDB 可用的调试信息

PROGRAM   := hello      # 设置运行程序名

SRCDIRS   := .          # 源程序位于当前目录下

SRCEXTS   := .c         # 源程序文件只有 .c 一种类型

CFLAGS    := `pkg-config --cflags gtk+-2.0`  # CFLAGS

LDFLAGS   := `pkg-config --libs gtk+-2.0`    # LDFLAGS

######################################
# Copyright (c) 1997 George Foot (george.foot@merton.ox.ac.uk)
# All rights reserved.
######################################
#目标（可执行文档）名称，库（譬如stdcx,iostr,mysql等），头文件路径
DESTINATION := test
LIBS :=
INCLUDES := .


RM := rm -f
#C,CC或CPP文件的后缀
PS=cpp
# GNU Make的隐含变量定义
CC=g++
CPPFLAGS = -g -Wall -O3 -march=i486
CPPFLAGS += $(addprefix -I,$(INCLUDES))
CPPFLAGS += -MMD

#以下部分无需修改
SOURCE := $(wildcard *.$(PS))
OBJS := $(patsubst %.$(PS),%.o,$(SOURCE))
DEPS := $(patsubst %.o,%.d,$(OBJS))
MISSING_DEPS := $(filter-out $(wildcard $(DEPS)),$(DEPS))
MISSING_DEPS_SOURCES := $(wildcard $(patsubst %.d,%.$(PS),$(MISSING_DEPS)))

.PHONY : all deps objs clean rebuild

all : $(DESTINATION)

deps : $(DEPS)
        $(CC) -MM -MMD $(SOURCE)

objs : $(OBJS)

clean :
        @$(RM) *.o
        @$(RM) *.d
        @$(RM) $(DESTINATION)

rebuild: clean all

ifneq ($(MISSING_DEPS),)
$(MISSING_DEPS) :
        @$(RM) $(patsubst %.d,%.o,$@)
endif

-include $(DEPS)

$(DESTINATION) : $(OBJS)
        $(CC) -o $(DESTINATION) $(OBJS) $(addprefix -l,$(LIBS))
#结束

• 原作者是Gorge Foot，写这个Makefile的时候还是一个学生
• ":="赋值，和"="不同的是，":="在赋值的同时，会将赋值语句中所有的变量就地展开，也就是说，A:=$(B)后，B的值的改变不再影响A
• 隐含规则。GUN Make在不特别指定的情况下会使用诸如以下编译命令：$(CC) $(CFLAGS) $(CPPFLAGS) $(TARGET_ARCH) -c $< -o $@，这也是为什么这个Makefile最后一个命令没有添加$(CPPFLAGS)的原因，因为缺省是包含这个变量的
• 函数和变量很相似："$ (函数名，空格，一列由逗号分隔的参数)"
• SOURCES = $(wildcard *.cpp) 列出工作目录下文件名满足"*.cpp"条件的文件，以空格分隔，并将列表赋给SOURCE变量
• patsubst函数：3个参数。功能是将第三个参数中的每一项（由空格分隔）符合第一个参数描述的部分替换成第二个参数制定的值
• addprefix函数：2个参数。将源串（第2个参数，由空格分隔）中的每一项添加前缀（第1个参数）
• filter-out函数：2个参数。从第二串中过滤掉包含在第一个串中的项
• $(CC) -MM -MMD $(SOURCE) : 对每个源文件生成依赖(dependence，Make通过依赖规则来判断是否需要重新编译某个文件)，"D"生成".d"文件，-MM表示去掉 depends里面的系统的头文件(使用<>包含的头文件)（若使用-M则全部包含，事实上，系统头文件被修改的可能性极小，不需要执行依赖检查）
• .PHONY，不检查后面制定各项是否存在同名文件
• ifneg...else...endif，Makefile中的条件语句
• -include $(DEPS) : 将DEPS中的文件包含进来，"-"表示忽略文件不存在的错误
• @$(RM) *.o : 开头的"@"表示在Make的时候，不显示这条命令（GNU Make缺省是显示的)
• all : 作为第一个出现的目标项目，Make会将它作为主要和缺省项目("make"就表示"make all")
• deps : 只生成依赖文件(.d文件)
• objs : 为每一个源码程序生成或更新 '.d' 文件和'.o'文件
• clean : 删除所有'.d','.o'和可执行文件
• rebuild : clean然后重建
• 内部变量$@, $< $^ : 分别表示目标名(:前面的部分，比如all)，依靠列表（:后面的部分）中的第一个依靠文件，所有依靠文件

 上次的培训园地中介绍了GCC的编译过程、警告提示功能、库依赖、代码优化和程序调试六个方面的内容。这期是最后的一部分内容。

加速

在将源代码变成可执行文件的过程中，需要经过许多中间步骤，包含预处理、编译、汇编和连接。这些过程实际上是由不同的程序负责完成的。大多数情况下GCC可以为Linux程序员完成所有的后台工作，自动调用相应程序进行处理。

这 样做有一个很明显的缺点，就是GCC在处理每一个源文件时，最终都需要生成好几个临时文件才能完成相应的工作，从而无形中导致处理速度变慢。例如，GCC 在处理一个源文件时，可能需要一个临时文件来保存预处理的输出、一个临时文件来保存编译器的输出、一个临时文件来保存汇编器的输出，而读写这些临时文件显 然需要耗费一定的时间。当软件项目变得非常庞大的时候，花费在这上面的代价可能会变得很沉重。

解决的办法是，使用Linux提供的一种更加高效的通信方式—管道。它可以用来同时连接两个程序，其中一个程序的输出将被直接作为另一个程序的输入，这样就可以避免使用临时文件，但编译时却需要消耗更多的内存。

在编译过程中使用管道是由GCC的-pipe选项决定的。下面的这条命令就是借助GCC的管道功能来提高编译速度的：

# gcc -pipe foo.c -o foo

在编译小型工程时使用管道，编译时间上的差异可能还不是很明显，但在源代码非常多的大型工程中，差异将变得非常明显。

文件扩展名

在使用GCC的过程中，用户对一些常用的扩展名一定要熟悉，并知道其含义。为了方便大家学习使用GCC，在此将这些扩展名罗列如下：

.c C原始程序；

.C C++原始程序；

.cc C++原始程序；

.cxx C++原始程序；

.m Objective-C原始程序；

.i 已经过预处理的C原始程序；

.ii 已经过预处理之C++原始程序；

.s 组合语言原始程序；

.S 组合语言原始程序；

.h 预处理文件(标头文件)；

.o 目标文件；

.a 存档文件。

GCC常用选项

GCC作为Linux下C/C++重要的编译环境，功能强大，编译选项繁多。为了方便大家日后编译方便，在此将常用的选项及说明罗列出来如下：

-c 通知GCC取消链接步骤，即编译源码并在最后生成目标文件；

-Dmacro 定义指定的宏，使它能够通过源码中的#ifdef进行检验；

-E 不经过编译预处理程序的输出而输送至标准输出；

-g3 获得有关调试程序的详细信息，它不能与-o选项联合使用；

-Idirectory 在包含文件搜索路径的起点处添加指定目录；

-llibrary 提示链接程序在创建最终可执行文件时包含指定的库；

-O、-O2、-O3 将优化状态打开，该选项不能与-g选项联合使用；

-S 要求编译程序生成来自源代码的汇编程序输出；

-v 启动所有警报；

-Wall 在发生警报时取消编译操作，即将警报看作是错误；

-Werror 在发生警报时取消编译操作，即把报警当作是错误；

-w 禁止所有的报警。

小结

GCC 是在Linux下开发程序时必须掌握的工具之一。本文对GCC做了一个简要的介绍，主要讲述了如何使用GCC编译程序、产生警告信息、调试程序和加快 GCC的编译速度。对所有希望早日跨入Linux开发者行列的人来说，GCC就是成为一名优秀的Linux程序员的起跑线。

3. 关于sqrt,sin和cos函数
就算是引入math.h头文件，也不会找到sqrt,sin和cos函数。应该用链接库来解决。
有时候我们使用了某个函数,但是我们不知道库的名字,这个时候怎么办呢?很抱 歉,对于这个问题我也不知道答案,我只有一个傻办法.首先, 我到标准库路径下面去找看看有没有和我用的函数相关的库,我就这样找到了线程(thread)函数的库文件(libpthread.a). 当然,如果找不到,只有一个笨方法.比如我要找sin这个函数所在的库. 就只好用 nm -o /lib/*.so|grep sin>~/sin 命令,然后看~/sin文件,到那里面去找了. 在sin文件当中,我会找到这样的一行libm-2.1.2.so:00009fa0 W sin 这样我就知道了sin在 libm-2.1.2.so库里面,我用 -lm选项就可以了(去掉前面的lib和后面的版本标志,就剩下m了所以是 -lm). 

sysinfo.o : ../sysinfo.c ../sysinfo.h
 gcc -c -g $(CFLAG) ../sysinfo.c

clean:
 del $(PROGRAM) $(OBJECT)

以上是mingw在windows下的一个范本。

   #ifndef COUNTED_PTR_HPP
   #define COUNTED_PTR_HPP

   /*class for counted reference semantics
    *-deletes the object to which it refers when the last CountedPtr
    * that refers to it is destroyed
    */
   template <class T>
   class CountedPtr {
     private:
       T* ptr;        // pointer to the value
       long* count;   // shared number of owners

     public:
       //initialize pointer with existing pointer
       //-requires that the pointer p is a return value of new
       explicit CountedPtr (T* p=0)
        : ptr(p), count(new long(1)) {
       }

       //copy pointer (one more owner)
       CountedPtr (const CountedPtr<T>& p) throw()
        : ptr(p.ptr), count(p.count) {
           ++*count;
       }

       //destructor (delete value if this was the last owner)
       ~CountedPtr () throw() {
           dispose();
       }

       //assignment (unshare old and share new value)
       CountedPtr<T>& operator= (const CountedPtr<T>& p) throw() {
           if (this != &p) {
               dispose();
               ptr = p.ptr;
               count = p.count;
               ++*count;
           }
           return *this;
       }

       //access the value to which the pointer refers
       T& operator*() const throw() {
           return *ptr;
       }
       T* operator->() const throw() {
           return ptr;
       }

     private:
       void dispose() {
           if (--*count == 0) {
                delete count;
                delete ptr;
           }
       }
   };

   #endif /*COUNTED_PTR_HPP*/

下载ACE5.5源码包之后，就马上开始编译：

首先参考ACE-Install.htm,其中说到Cygwin下的ACE的编译方法：

1. Open a Cygwin shell. Set your PATH environment variable so your Cygwin bin directory is first:

          % export PATH=//c/cygwin/bin:$PATH       

   Note Cygwin uses ``/'' as directory separator, and ``//X'' as a notation for Win32 drive X. Note also that you can't use ``c:/cygwin/bin'' because, for Cygwin, ``:'' is path separator character, as in UNIX.
   
   

2. Add an ACE_ROOT environment variable pointing to the root of your ACE wrappers source tree:

          % export ACE_ROOT=c:/work/cygwin/ACE_wrappers       

   Note here you can't use the ``//X'' Cygwin notation as this is seen by Cygwin's compiler and it doesn't support that (it does support ``/'' as directory separator however).

   From now on, we will refer to the root directory of the ACE source tree as $ACE_ROOT.
   
   

3. Create a file called config.h in the $ACE_ROOT/ace directory that contains:

          #include "ace/config-cygwin32.h"       

4. Create a file called platform_macros.GNU in the $ACE_ROOT/include/makeinclude directory containing:

          include $(ACE_ROOT)/include/makeinclude/platform_cygwin32.GNU       

   In the above text, don't replace $(ACE_ROOT) with the actual directory, GNU make will take the value from the environment variable you defined previously.
5. On the Cygwin shell, change to the $ACE_ROOT/ace directory and run make:

          % cd $ACE_ROOT/ace       % make       

   This should create libACE.dll (the Win32 shared library) and libACE.dll.a (the Win32 import library for the DLL). Note the name for the ACE DLL on Cygwin follows the UNIX convention.
   
   

   If you want static libs also, you may run:

          % make static_libs=1

但是死活编译不成功，make返回Error2,烦死。

google一下，大部分人都是这样编译过了，但是本机就死活不行，

后来终于找到了一个文章，里面说了一种不同于官方文档的编译方法：

先设置ACE_ROOT环境，命令：“vi /etc/profile”在其中加入4行
ACE_ROOT=~/ACE_wrappers export ACE_ROOTLD_LIBRARY_PATH=$ACE_ROOT/ace:$LD_LIBRARY_PATH export LD_LIBRARY_PATH我是加在“export PATH USER….”后的。完成后将/etc/profile执行一次，
命令：“chmod 555 /etc/profile”“/etc/profile”这样我们的ACE_ROOT就设置好了，
可以用如下命令查看ACE_ROOT是否设置好了：“echo $ACE_ROOT”,

然后执行官方文档的3，4步骤，

最后：

       % cd $ACE_ROOT/ace       %  make static_libs=1

经过漫长的等待，终于搞定！发文记录一下。

1、定义ACE_ROOT

export ACE_ROOT＝/datas/ACE_wrappers;

2、定义配置文件，$ACE_ROOT/ace/config.h,该文件包含和平台相关的配置文件：

如在linux平台下，内容为

#include "ace/config-linux.h" 
3、Create a build configuration file, $ACE_ROOT/include/makeinclude/platform_macros.GNU, that contains the appropriate platform/compiler-specific Makefile configurations, e.g., 
   include $(ACE_ROOT)/include/makeinclude/platform_linux.GNU 
4、Note that because ACE builds shared libraries, you'll need to set LD_LIBRARY_PATH (or equivalent for your platform) to the directory where binary version of the ACE library is built into. For example, you probably want to do something like the following: 
   % setenv LD_LIBRARY_PATH $ACE_ROOT/lib:$LD_LIBRARY_PATH
5、When all this is done, hopefully all you'll need to do is type: 
% make
6、在fedora6上的config.h的第一行加上如下语句：
#define ACE_GCC_HAS_TEMPLATE_INSTANTIATION_VISIBILITY_ATTRS 1