简介：libpcap（数据包捕获函数库）是Unix/Linux平台上广泛使用的网络数据包捕获开发库，支持原始数据包捕获、自定义数据包发送、流量采集统计与规则过滤，也是tcpdump、Wireshark等常见网络工具的重要底层依赖。但在离线、内网或无外网编译环境下，手动编译libpcap常被gcc、m4、bison、flex等依赖项卡住，版本不匹配或安装顺序错误都会导致反复报错。压缩包内共2个文件，包括1个tar源码包和1个sh安装脚本，总大小43.29MB，其中的sh脚本可自动完成编译与安装，并已包含libpcap 1.10.1及全套依赖源码。目前已有1036人学习/下载，说明该离线安装方案具备较高的参考价值。开启资源后，读者可在不联网的服务器或实验环境中直接运行脚本，免去逐个下载、编译依赖的繁琐流程；保留的完整依赖源码也便于核对版本、排查安装异常，并在其他离线机器上重复使用，适合Linux运维、网络安全测试及希望快速搭建抓包开发环境的开发者。 干内网运维或者安全分析的朋友，多半遇到过这种场景：机器上要排查流量问题，需要tcpdump，跑过去一敲命令，发现gcc没有、make没有，yum连不上外网，手里只有一个U盘。系统装不上libpcap，抓包工作就卡在原地。libpcap本身是个很成熟的库，从源码编译并不复杂，麻烦的是它背后站着一串编译工具和辅助库——gcc、m4、bison、flex，一个都不能缺，而且安装顺序有讲究。
这篇文章把我最近一次在完全离线的CentOS 7环境里搞定libpcap的完整过程整理出来，包括自动安装脚本的设计思路、版本搭配的选择逻辑，以及实际执行中最容易翻车的几个报错和完整排查方法。如果你也遇到"内网要装libpcap"这类需求，可以直接把脚本拿走用，报错排查部分也值得先看一眼，能帮你少走不少弯路。
1. libpcap不是单个包，而是一条依赖链
1.1 抓包需求背后的完整编译链路
libpcap是一个捕包接口库，tcpdump、nmap、wireshark这些工具底层都在依赖它。它的工作方式是从网卡驱动那里拿到原始数据帧，再按pcap格式交给上层应用。在内网里排查ARP攻击、看某台机器到底发了什么包，都绕不开它。
问题在于，从源码安装libpcap并不是"解压、make、make install"三个命令这么简单。整个编译过程要经历configure、make、make install三个阶段，而每个阶段都依赖外部工具：
- configure阶段：需要一套完整的POSIX工具链，包括sed、awk、sh这些，通常最小化安装的CentOS也会带。
- make阶段：需要make本身，这个很多系统会忽略。
- 代码生成阶段：libpcap源码里的过滤器表达式解析器，是用bison生成的grammar.y；词法扫描器，是用flex生成的scanner.l。如果发布包里没有预生成代码，或者configure检测不到flex和bison，编译就直接中断。
- C代码编译阶段：需要gcc这套真正的C编译器。
而这些工具自身也还有下一层依赖。bison是C语言写的，编译它的时候，configure脚本会调用m4来完成一些宏展开；flex同样对m4有版本要求。m4是老古董级的宏处理器，但Bison和Flex的构建体系到现在依然重度依赖它。
1.2 每个依赖在整条链里具体干什么
很多教程只说"把gcc、m4、bison、flex装上就行"，但从没讲清楚为什么。这里我展开说一下，理解之后你排查问题会快得多：
- gcc：把C源码编译成目标文件和可执行程序。libpcap、flex、bison都是C/C++项目，没有编译器寸步难行。
- make：根据Makefile规则，按依赖关系自动编译和安装。configure会生成Makefile，但执行构建还得有make。
- m4：宏处理器。autoconf生成的configure脚本会自动搜索m4，bison构建时会调用m4处理一些数据文件。很多老系统带的m4版本过低，直接导致bison或flex的configure报错。
- flex：词法分析器生成器。libpcap中负责把输入字节流切成token，对应的源文件是scanner.l。
- bison：语法分析器生成器。libpcap中负责把token组合成语法树，用于过滤表达式解析，对应的源文件是grammar.y。
它们之间是一个串行依赖：gcc和make在最底层，m4在中间层，flex和bison在上层，最后才是libpcap。顺序反了，后一个包的configure就会检测不到前置工具，然后给你一句莫名其妙的错误。
1.3 为什么不能靠yum一把梭
在有网环境下，一条yum install -y libpcap libpcap-devel就能解决，包管理器会自动把glibc、flex、bison这些依赖全部拉起来。可一旦到了物理隔离的内网，yum源不可用，你手里唯一的途径就是手动搬运安装包。如果只搬一个libpcap的rpm回来，安装时会报一堆依赖缺失；如果你对依赖链没有全局认识，就会陷入"装A发现缺B，装B发现缺C，装C又发现A版本不够"的死循环。提前把整条链理清楚，比临时去试要高效得多。
2. 依赖包版本搭配，不同环境的选型逻辑
2.1 我建议的版本组合
离线环境里选版本，我的原则是"能稳定编译通过优先，其次再去追新"。如果目标系统是CentOS 7，下面这套版本组合我实测比较稳：
| 软件包 | 建议版本 | 作用 | 备注 |
|---|---|---|---|
| gcc / gcc-c++ | 系统自带4.8.x即可 | C/C++编译器 | 无需升级，除非要编新版bison |
| make | 系统自带3.82 | 构建工具 | 一般默认就有 |
| m4 | 1.4.19 | 宏处理器 | 别用太旧的1.4.16 |
| flex | 2.6.4 | 词法分析器生成器 | 2.5.x也能用，2.6.x更稳 |
| bison | 3.0.4 | 语法分析器生成器 | 老gcc环境下别上3.7+ |
| libpcap | 1.10.4 | 抓包库本体 | 1.10系比较稳定 |
2.2 版本选择的底层依据
为什么bison这里我特意压到3.0.4，很多人会不理解。因为新版bison从3.5往后，构建bison自身源码需要较完整的C++11编译器支持，CentOS 7自带的g++是4.8.5，只支持部分C++11特性。虽然在某些场景下能勉强编过，但一旦碰到模板展开或正则表达式库相关代码，就会抛出一堆看不懂的报错。而libpcap对bison版本的要求其实没那么苛刻，只要语法分析器输出正常，3.0.4完全够用。
反过来，如果你的目标机器g++版本在8以上，比如比较新的Linux发行版，那就可以放心用bison 3.8.2。所以我建议把bison版本做成一个可配置的变量，而不是在脚本里写死。
m4版本也不能胡来。flex 2.6.4的configure脚本会检查m4版本，低于1.4.6直接拒绝。CentOS 7自带的m4是1.4.16，其实够用，但如果你装了新的bison 3.8，它对m4的要求会更高。统一用m4 1.4.19最省心。
2.3 一个版本搭配表
给不同环境做个快速选型参考：
| 目标系统 | gcc/g++ | m4 | flex | bison | libpcap |
|---|---|---|---|---|---|
| CentOS 7 / RHEL 7 | 4.8.5（自带） | 1.4.19 | 2.6.4 | 3.0.4 | 1.10.4 |
| CentOS 8 / RHEL 8 | 8.x（自带） | 1.4.19 | 2.6.4 | 3.7.6 | 1.10.4 |
| Ubuntu 20.04+ | 9.x（自带） | 1.4.18 | 2.6.4 | 3.8.2 | 1.10.4 |
| 老旧机器gcc偏低 | 需自备或rpm源 | 1.4.19 | 2.5.39 | 2.7.1 | 1.9.1 |
这个表不是绝对的，但按这个组合走，踩坑概率会小很多。
3. 装之前先做环境体检，判断哪些依赖能省
3.1 体检命令
离线环境下，每多编一个包就多一分风险，所以第一步不是闷头装，而是先看机器上已经有什么。我自己习惯把这几个命令一次性跑完：
cat /etc/redhat-release getconf LONG_BIT which gcc g++ make m4 flex bison yacc lex 2>/dev/null gcc --version 2>/dev/null | head -1 make --version 2>/dev/null | head -1 m4 --version 2>/dev/null | head -1 rpm -q kernel-devel glibc-devel libgcc 2>/dev/null echo $PATH输出结果会告诉你两件事：哪些工具已经有了，哪些工具虽然有但可能不完整。比如gcc命令存在，不代表g++也存在，因为RHEL系列把gcc和gcc-c++分成了两个包，最小化安装经常只带gcc不带g++。
3.2 体检结果怎么判断
判断逻辑其实很简单：
- gcc存在且能正常编译hello world，那么gcc这个依赖就可以跳过，不必非得离线编译一遍gcc，那是个巨大的工程。
- make存在，基本就不用管了，make 3.82编这些包没有兼容性问题。
- m4存在且版本不低于1.4.16，可以先用着；如果configure报错再换。
- flex和bison大概率是没有的，因为它们是开发工具，生产服务器一般不装。
- kernel-devel一定重点看，libpcap在Linux上需要内核头文件来定义packet socket相关结构，缺了它后续编译出的libpcap功能不完整。
3.3 最常见的"半吊子"环境
我遇到最多的情况是用户说"机器上有gcc"，结果一查只有gcc的rpm记录，gcc命令压根不存在，或者gcc命令在但缺少libc库的开发头文件。有一个隐蔽的坑：gcc --version能输出版本号，但实际编译一个最简单的.c文件时，报fatal error: stdio.h: No such file or directory，这说明glibc-devel没装，头文件路径是空的。离线环境下这种问题最容易让人抓狂，因为你根本没想到编译器本体在，头文件却不在。
所以体检阶段，我强烈建议顺手在/tmp下写个hello.c，执行一遍gcc hello.c -o hello && ./hello，确认它能真正产出可执行文件。这个检查花不了一分钟，却能过滤掉一大半"假环境"问题。
4. 离线安装包怎么来：ISO本地源、yumdownloader与源码包
4.1 方案一：用CentOS ISO做本地yum源
如果手里有CentOS 7的ISO镜像，这是最省事的路子。挂载ISO，配置一个本地yum源，gcc、gcc-c++、make、kernel-devel一次性装齐，半小时内搞定基础编译链。具体做法：
mkdir -p /mnt/centos mount -o loop /path/to/CentOS-7-x86_64-DVD-1810.iso /mnt/centos cat > /etc/yum.repos.d/local.repo <<'EOF' [local] name=CentOS-$releasever - Local baseurl=file:///mnt/centos enabled=1 gpgcheck=0 EOF yum clean all yum makecache yum install -y gcc gcc-c++ make kernel-devel注意，ISO里的包一般是发行版发布时的版本，版本偏老些没关系，编译libpcap完全够用。装完后建议把kernel-devel版本和系统内核版本对一下，执行uname -r确认，因为内核开发包必须匹配当前内核才能正确编译内核模块，不过libpcap走的是packet socket，不需要编译内核模块，这里主要是为了拿到头文件。
4.2 方案二：联网机器抓rpm包搬运
如果没有ISO，但内网有一台可以联网的同版本机器，可以用yumdownloader把依赖的rpm全部抓下来，再通过U盘或内网传输搬到目标机。步骤：
yum install -y yum-utils mkdir -p /tmp/rpms yumdownloader --resolve --destdir=/tmp/rpms \ gcc gcc-c++ make kernel-devel glibc-devel tar czf rpms.tar.gz /tmp/rpms把rpms.tar.gz拷到目标机器后：
mkdir -p /tmp/rpms && tar xzf rpms.tar.gz -C /tmp/rpms yum install -y /tmp/rpms/rpms/*.rpm这个方式的坑在于：yumdownloader --resolve只解决rpm依赖，不会把非rpm方式安装的源码包依赖也一起解决。而且如果两台机器的系统小版本差距过大，抓来的包可能因为glibc版本不兼容而装不上。所以尽量找同一版本、同一架构的机器。
4.3 方案三：源码包编译
源码包方式，是我这篇脚本的主线。它的优点是：不依赖rpm仓库，理论上任何Linux发行版都能用；缺点是每个包都要自己configure、make、make install一遍。
离线机器上源码包需要提前备好，目录结构我习惯这样规划：
/opt/src/ ├── m4-1.4.19.tar.gz ├── flex-2.6.4.tar.gz ├── bison-3.0.4.tar.gz └── libpcap-1.10.4.tar.gz下载的时候，我建议在联网机器上同时执行sha256sum生成校验值，目标机解压前先核对，防止U盘或网络传输过程中文件损坏。以前我偷懒跳过这一步，结果flex的压缩包在拷贝时损坏，解压能成但configure阶段报一堆乱码，排查了好久才发现是包坏了。
另外提一句，源码包尽量从官方FTP或GitHub release下载，不要随便找个镜像站，被篡改的源码一旦编译进生产环境，问题会很严重。官方校验值要一并核对。
5. 自动安装脚本：顺序、环境变量和失败即停
5.1 完整脚本
核心思路就三句话：按依赖顺序编译、统一环境变量、失败立即终止。下面是简化后可用的完整脚本，我已经在CentOS 7上跑过：
#!/bin/bash # libpcap offline auto installer # Usage: bash install_libpcap.sh [source_dir] [install_dir] set -euo pipefail SRC_DIR="${1:-/opt/src}" INSTALL_DIR="${2:-/usr/local}" LOG_FILE="/tmp/libpcap_install.log" # 统一依赖的安装路径 export PATH="${INSTALL_DIR}/bin:${PATH}" export CPPFLAGS="-I${INSTALL_DIR}/include" export LDFLAGS="-L${INSTALL_DIR}/lib -L${INSTALL_DIR}/lib64" export LD_LIBRARY_PATH="${INSTALL_DIR}/lib:${INSTALL_DIR}/lib64:${LD_LIBRARY_PATH:-}" export PKG_CONFIG_PATH="${INSTALL_DIR}/lib/pkgconfig:${PKG_CONFIG_PATH:-}" log() { echo "$(date '+%Y-%m-%d %H:%M:%S') $*" | tee -a "${LOG_FILE}" } build_pkg() { local pkg_dir="$1" shift if [ ! -d "${SRC_DIR}/${pkg_dir}" ]; then log "[ERROR] source dir not found: ${SRC_DIR}/${pkg_dir}" return 1 fi cd "${SRC_DIR}/${pkg_dir}" log "===== build ${pkg_dir} =====" if [ ! -f "Makefile" ]; then ./configure --prefix="${INSTALL_DIR}" "$@" >> "${LOG_FILE}" 2>&1 || { log "[ERROR] configure failed for ${pkg_dir}" return 1 } fi make -j"$(nproc)" >> "${LOG_FILE}" 2>&1 || { log "[ERROR] make failed for ${pkg_dir}" return 1 } make install >> "${LOG_FILE}" 2>&1 || { log "[ERROR] make install failed for ${pkg_dir}" return 1 } log "[OK] ${pkg_dir} installed" } # ---------- build order ---------- build_pkg m4-1.4.19 build_pkg flex-2.6.4 build_pkg bison-3.0.4 build_pkg libpcap-1.10.4 # 让动态链接器找到新的libpcap.so echo "${INSTALL_DIR}/lib" > /etc/ld.so.conf.d/offline-libpcap.conf echo "${INSTALL_DIR}/lib64" >> /etc/ld.so.conf.d/offline-libpcap.conf ldconfig log "======== all done ========"5.2 脚本设计的六个关键点
为什么脚本要这么写，而不是简单地一条条命令堆下去，有六个细节值得说：
第一，set -euo pipefail是底线。-e让脚本在第一个报错时退出，-u防止未定义变量在脚本里炸出意想不到的路径，-o pipefail让管道前一个命令失败时整条管道返回失败。离线编译最怕脚本跑了一半把错误忽略掉，最后装出来一个残缺的libpcap，后续排查更痛苦。
第二，build_pkg函数把configure、make、make install封装成了三次独立检查。为什么不在configure成功后就默认make一定成功？因为configure阶段检查的是环境，make阶段暴露的是源码编译问题，二者失败原因完全不同。分开记录日志和错误，能让你快速定位到底卡在哪一步。
第三，--prefix统一指定为/usr/local，这比默认值更重要。如果不显式指定，flex默认装在/usr/local还好，但有些包默认已经配置了别的路径，导致头文件和库文件散落多处，后面libpcap configure时找不到flex的库，就得去猜路径。
第四，环境变量必须在编译开始前export。CPPFLAGS和LDFLAGS的作用是告诉后面的configure和make：所有依赖的头文件和库文件都在/usr/local/include和/usr/local/lib下。这几个变量不设，即使把依赖都装好了，后面的包还是找不到它们。
第五，安装顺序是硬性的：m4 -> flex -> bison -> libpcap。为什么flex在bison前面？因为bison的configure脚本会用m4，flex的configure脚本也会用m4，但二者之间没有强依赖。而libpcap在configure阶段需要同时看到flex和bison，所以它必须在最后。
第六，ldconfig和ld.so.conf.d文件不能省。libpcap编译完，如果不刷新动态链接器缓存，运行tcpdump时会报libpcap.so.1: cannot open shared object file。这个问题在后续验证阶段会出现，所以脚本里提前处理掉。
5.3 脚本怎么扩展
实际使用时，你可能有自己的版本偏好，把版本号改成3.8的bison，只需改相应的目录名即可。但注意，如果换用bison 3.7+，那执行脚本前必须确认g++版本够新。另外，如果你的目标机器已经有部分依赖，比如系统自带m4且版本满足，完全可以跳过对应的build_pkg行，不必重复编译。
如果文件是tar.xz或tar.bz2，脚本里没写解压逻辑，因为我觉得解压动作应该在脚本外手动完成，更可控。执行前把所有tar包预先解压到/opt/src下，再跑脚本，避免脚本误删或覆盖已有源码目录。
6. 实际执行时最常翻车的4个报错与排查思路
6.1 configure: error: GNU M4 1.4.6 or later is required
这是编译flex或bison时最常见的报错。症状很直白：./configure执行到一半，抛出一句要求M4版本大于等于1.4.6，然后退出。
排查链路是这样的：先看日志尾部，确认是哪个包报的错。然后用m4 --version查看本机m4版本。CentOS 7自带m4是1.4.16，按理说满足要求，但如果你的PATH里没有把/usr/local/bin放进去，configure会优先找到系统老版本的m4；如果本机m4缺失，那configure直接说找不到。
解决办法就是先把m4装上。装m4本身没什么坑，三步走完。但如果你用的是我上面的脚本，脚本已经设置了PATH包含${INSTALL_DIR}/bin，所以configure会在m4安装后被正确找到。这里特别提醒一句：千万不要跳过m4，直接编flex，很多人在这一步节省时间，最后反而花更多时间排查。
6.2 flex is required / yacc: command not found
libpcap的configure脚本在检测flex和bison时，会明确检查版本和路径。如果你跳过了flex，或者flex装到了非标准路径，configure会报configure: error: flex is required；如果flex装了但bison没装，到make阶段会出现yacc: command not found。
这里有个容易混淆的细节：libpcap的Makefile里，语法分析器通常通过YACC变量调用，而YACC通常指向bison -y。有些系统上你只装了bison，但/usr/bin/yacc这个符号链接不存在，make就会报找不到yacc。排查方法很简单：
which yacc flex bison ls -l /usr/bin/yacc如果yacc不存在，创建符号链接：
ln -s /usr/local/bin/bison /usr/bin/yacc不过这个方案比较粗暴。更干净的做法是确保bison安装路径在PATH里，并重新运行libpcap的configure脚本，让configure重新检测YACC变量并写入Makefile。
6.3 cannot find -lfl / undefined reference to `libfl'
这个错一般发生在你重新编译其他依赖libpcap的程序时，或者在编译过程中某个测试程序链接flex库时。-lfl指的就是libfl.a，flex安装后生成的词法分析器库。
报这个错，最直接的原因是flex编译安装成功了，但libfl库的路径没被链接器找到。CentOS 7的链接器默认搜索路径里不包含/usr/local/lib，你明明看到/usr/local/lib/libfl.a存在，链接器就是找不到。
排查和解决思路：
ls -l /usr/local/lib/libfl* echo ${LDFLAGS} echo ${LD_LIBRARY_PATH} ldconfig -p | grep fl如果LDFLAGS里没加-L/usr/local/lib，把它补上重新编译；如果动态库运行时报找不到libfl.so，确认/etc/ld.so.conf.d/offline-libpcap.conf里的路径正确并执行了ldconfig。这个坑属于"装完必须配路径"的经典案例，很多初学者栽在这里，因为安装本身成功了，问题出在后续使用阶段。
6.4 g++: command not found
如果你用的bison版本是3.7以上，编译bison时configure会检测C++编译器，因为新版bison的源码是C++写的。这个时候一个古老但常见的坑就出现了：系统装了gcc，但没装gcc-c++。
排查方式：
which g++ g++ --version如果输出是空的，说明gcc-c++缺失。解决办法有两个：一是用之前讲过的ISO本地源或yumdownloader方式补装gcc-c++；二是把bison版本换成3.0.4，这样它还是纯C的构建体系，不要求g++。
我个人的建议是，如果只是为了编libpcap，bison 3.0.4足矣，没必要为了追新去折腾g++。除非你的项目需要用到新版bison生成特定语法，否则少引入一个变量，就少一份风险。
7. 装完验证三件套：库、编译、真实抓包
7.1 库文件确认
安装完成后，先确认libpcap库确实存在于预期位置：
ls -l /usr/local/lib/libpcap* ls -l /usr/local/include/pcap* ldconfig -p | grep pcap如果ldconfig -p里能看到pcap相关的输出，说明动态链接器已经识别了新的库。如果看不到，检查/etc/ld.so.conf.d/offline-libpcap.conf文件是否创建，并执行ldconfig。
7.2 用一个小程序验证API调用
库文件在不在，不等于API能正常调用。写一个几十行的C程序，调用pcap_findalldevs枚举网卡，这是确认libpcap真正工作的最小验证：
#include <stdio.h> #include <pcap/pcap.h> int main(void) { char errbuf[PCAP_ERRBUF_SIZE]; pcap_if_t *alldevs = NULL; if (pcap_findalldevs(&alldevs, errbuf) == -1) { fprintf(stderr, "pcap_findalldevs: %s\n", errbuf); return 1; } for (pcap_if_t *d = alldevs; d != NULL; d = d->next) { printf("%s\n", d->name); } pcap_freealldevs(alldevs); return 0; }编译时用下面的命令，注意-L和-l参数顺序，-lpcap必须放在源码文件后面：
gcc -o test_pcap test_pcap.c -I/usr/local/include -L/usr/local/lib -lpcap ./test_pcap正常情况下会输出eth0、lo之类的网卡名称。如果程序报error while loading shared libraries: libpcap.so.1，说明动态链接器还没找到库路径，回到7.1检查ldconfig配置。
我还用ldd test_pcap看过它的动态库依赖，能看到libpcap.so.1 => /usr/local/lib/libpcap.so.1这样的输出，这能确认程序实际链接的库来自哪里，也方便排查是不是链接到了系统自带的旧版libpcap。
7.3 tcpdump验证真实抓包
API能跑了还不够，最好用tcpdump直接抓一下包，验证内核态的packet socket确实可用：
tcpdump -i eth0 -c 5如果tcpdump还没装，可以同样离线编译一个，它的依赖只有libpcap，无需其他额外工具。也可以先用tcpdump -D列出网卡，确认tcpdump能识别到接口。能抓到包，说明从libpcap到内核packet socket整条链路都是通的。
7.4 环境变量持久化
最后一个小细节：脚本里export的环境变量只对当前shell有效。为了下次登录不用重新配置，在/etc/profile.d/libpcap_offline.sh写入：
export PATH=/usr/local/bin:$PATH export LD_LIBRARY_PATH=/usr/local/lib:/usr/local/lib64:$LD_LIBRARY_PATHsource一下再验证。这样以后别的用户登录也会自动带上这些路径，避免临时环境变量忘记设置导致各种"找不到库"的诡异问题。
我在实际用途中体会最深的一点是：离线安装这类工具链，真正难的不是某个包编译不过，而是对整体依赖链缺乏全局认识，导致反复试错，每层都试一遍才摸清顺序。这份脚本和对应的排查思路，我现在遇到内网机器就直接复用，从拆包到tcpdump能抓包，基本五分钟内结束。如果你也常处理离线环境，建议把这套流程固化成自己的工具包，遇到一台新机器就按"体检、补基础链、编译依赖、编译本体、验证"这个节奏走，效率会高很多。
本文还有配套的精品资源，点击获取
