简介：面向 Linux 网络开发、协议分析、安全测试与运维人员的 libpcap 离线安装包，针对隔离环境或无外网机器上依赖缺失、编译链条复杂、逐个安装耗时等问题而整理。资源共 2 个文件，以一份 sh 自动化安装脚本和一份 tar 依赖归档为主，压缩包约 43.29MB；其中集中收录 gcc、m4、bison、flex 及 libpcap 相关安装内容，通过脚本串联编译与安装流程，减少联网查找和手工配置成本。已有 1040 人学习下载，在离线部署场景中具备一定参考价值。读者可借助这套依赖集合与自动化思路快速搭建数据包捕获环境，开展网卡原始流量捕获、自定义数据包发送、流量采集统计和规则过滤等实验；版本集中归档也便于在隔离环境中复现、比对和排查编译问题，适合需要落地 libpcap 工具链的初中级用户参考。

1. 离线内网装 libpcap：为什么不能直接 yum，得把 gcc 到 flex 全链条自己编

一台没有外网的内网机器，业务侧要跑抓包分析，系统自带的 libpcap 版本太老或者压根没装，yum/apt 源不可达，rpm 包又缺依赖。这时候能走的只有源码离线安装：把 libpcap、gcc、m4、bison、flex 的源码包一起带进去，按顺序编译。所谓 libpcap 离线脚本自动安装，核心不是“一条命令装完”，而是把这条工具链的依赖顺序、版本咬合和安装前缀提前固化进脚本，让目标机在断网状态下也能从解压一路走到 make install。适合内网运维、安全分析环境准备、以及需要在隔离环境里补齐编译工具链的从业者。先泼一盆冷水：不是所有 libpcap 安装都需要 bison 和 flex，release 包和 git 包的差别直接决定依赖数量，这条边界要先摸清。

2. 依赖链拆解：gcc、m4、bison、flex 与 libpcap 的编译顺序和版本咬合

2.1 谁依赖谁：先分清构建期依赖和运行期依赖

libpcap 本身是一个 C 库，运行期不依赖 m4、bison、flex，真正需要它们的是构建过程。gcc 是编译任何 C 代码的基础，libpcap 的 configure 和 make 都离不开它。m4 是宏处理器，bison 的构建系统和部分生成规则会调用它。bison 负责把语法文件转成 C 解析器，flex 负责把词法规则转成 C 扫描器。libpcap 官方 release tarball 里通常已经包含了预生成的 grammar.c、scanner.c，所以直接./configure && make并不强制要求 bison/flex；但从 git 仓库拉下来的代码或者某些裁剪过的源码包，需要重新生成这些文件，这时候 bison 和 flex 就成了硬依赖。

离线脚本为了“一套包通吃”，一般会把四个依赖全部编进去。代价是编译时间变长，收益是碰到任何形态的 libpcap 源码都不会卡住。我一般会在脚本里加一个开关：--with-parser决定是否编译 bison/flex，纯 release 包安装时可以关掉，省一半时间。

还有一个容易被忽略的鸡蛋问题：编 gcc 需要 C 编译器，编 bison 需要 C 编译器，连 m4 自己都要 C 编译器。如果目标机连 cc 都没有，整条链就断了。常见做法是先在能联网的机器上编一个静态链接的 gcc 二进制带进去，或者确认目标机有系统自带的 cc（哪怕版本老一点）。只要有它，就能先把 m4、bison、flex 编出来，再用它们编新 gcc，最后编 libpcap。脚本里这条路径要写成条件分支：--use-system-cc走快路径，--rebuild-gcc走全量自举。

2.2 版本怎么选：别追最新，追能互相编译通过

离线环境没有回头路，版本选错就得重新打包。下面这张表是按 libpcap 构建场景整理的常见搭配，具体小版本以你手头源码包为准，原则是“老一代稳定版优先”：

gcc 那一行是整条链里最容易翻车的地方。gcc 源码树自带contrib/download_prerequisites，它会去外网拉 gmp、mpfr、mpc，离线环境跑这个脚本等于白跑，会卡在下载。解决办法有两个：一是提前把这三个包下好，放进 gcc 源码目录，让脚本检测到已存在文件后跳过下载；二是编译 gcc 时用--with-gmp=、--with-mpfr=、--with-mpc=指向已经装好的库。前者适合完全隔离的环境，后者适合系统里已经有一套数学库的情况。

2.3 目录与安装前缀：别往 /usr/local 一倒了事

离线脚本最怕污染系统目录。目标机可能已经有老版本 libpcap，直接覆盖 /usr/local/lib 下的 so 文件，后续其他程序链接到哪个版本就变成玄学。我一般会把整套工具链装到独立前缀，比如/opt/offline-stack，目录结构固定成四层：

OFFLINE_ROOT=/opt/offline-stack SRC_DIR="$OFFLINE_ROOT/src" # 放所有 tar 包 BUILD_DIR="$OFFLINE_ROOT/build" # 解压和编译目录 PREFIX="$OFFLINE_ROOT/prefix" # make install 目标 LOG_DIR="$OFFLINE_ROOT/logs" # 每个组件的 configure/make 日志

安装完成后，通过环境变量或者 wrapper 脚本把$PREFIX/bin放到 PATH 前面，把$PREFIX/lib加进LD_LIBRARY_PATH或写进 ld.so.conf。这样即使系统里有旧版 libpcap，也不会互相打架。脚本里所有路径都用变量拼，不写死绝对路径，换一台机器只需要改OFFLINE_ROOT一个值。

3. 脚本化落地：从解压到 make install 的五步可复现流程

3.1 环境预检：先把“能不能编”这件事确认掉

脚本第一步不是解压，是检查基础工具和磁盘空间。tar、make、sed、awk、grep 这些缺一个，后面全是白忙。系统 C 编译器也要探测，有就记下版本，没有就提示需要预置二进制 gcc。

#!/usr/bin/env bash set -euo pipefail OFFLINE_ROOT="${OFFLINE_ROOT:-/opt/offline-stack}" SRC_DIR="$OFFLINE_ROOT/src" BUILD_DIR="$OFFLINE_ROOT/build" PREFIX="$OFFLINE_ROOT/prefix" LOG_DIR="$OFFLINE_ROOT/logs" JOBS="${JOBS:-$(nproc)}" mkdir -p "$BUILD_DIR" "$PREFIX" "$LOG_DIR" # 基础命令检查，缺任何一个都直接退出 for cmd in tar make sed awk grep; do command -v "$cmd" >/dev/null 2>&1 || { echo "缺少基础命令: $cmd"; exit 1; } done # 探测系统 C 编译器，记录到日志供后续分支使用 if command -v gcc >/dev/null 2>&1; then gcc --version | head -1 | tee "$LOG_DIR/system-gcc.txt" HAVE_SYSTEM_CC=1 elif command -v cc >/dev/null 2>&1; then cc --version | head -1 | tee "$LOG_DIR/system-cc.txt" HAVE_SYSTEM_CC=1 else HAVE_SYSTEM_CC=0 echo "未发现系统 C 编译器，需要预置二进制 gcc 或 cc" | tee "$LOG_DIR/system-cc.txt" fi # 磁盘空间粗检，gcc 源码编译建议至少留 5GB AVAIL_KB=$(df -Pk "$OFFLINE_ROOT" | awk 'NR==2 {print $4}') if [ "$AVAIL_KB" -lt 5242880 ]; then echo "警告: $OFFLINE_ROOT 剩余空间不足 5GB，gcc 编译可能失败" fi

这段预检的逻辑很简单：先把“脚本能跑下去”的最低条件确认掉。set -euo pipefail保证任何一步失败都立即退出，不会带着错误往下走。JOBS默认取 CPU 核数，后面传给 make 的-j参数；内存小的机器要手动调低，否则 gcc 编译阶段容易 OOM。日志目录提前建好，每个组件的输出重定向到独立文件，出问题直接翻日志，不用在终端里往上滚。

3.2 先编 m4：用最简单的组件把工具链跑通

m4 是整条链里编译最快的组件，适合拿来验证编译器、make 和安装前缀是否正常。如果 m4 都编不过，后面的 gcc 和 libpcap 不用试。

M4_VER="${M4_VER:-1.4.19}" cd "$BUILD_DIR" tar -xf "$SRC_DIR/m4-${M4_VER}.tar.xz" cd "m4-${M4_VER}" ./configure --prefix="$PREFIX" \ > "$LOG_DIR/m4-configure.log" 2>&1 make -j"$JOBS" \ > "$LOG_DIR/m4-make.log" 2>&1 make install \ > "$LOG_DIR/m4-install.log" 2>&1

--prefix指向独立前缀，不碰系统目录。configure、make、install 三段日志分开存，哪一步失败看哪个文件。m4 装完后把$PREFIX/bin加到 PATH 最前面，后面 bison 的 configure 会优先找到这个新 m4，而不是系统里可能缺失的版本。

export PATH="$PREFIX/bin:$PATH" m4 --version | head -1

这一步的输出应该是新装的版本号。如果还是系统旧版本，说明 PATH 顺序不对，或者 shell 缓存了命令路径，用hash -r清一下。

3.3 编 bison 和 flex：注意 LEX 与 YACC 的环境变量

bison 和 flex 的编译流程和 m4 类似，但有两个细节。第一，bison 的 configure 会找 m4，如果前面 PATH 设置正确，它会直接用新 m4；第二，flex 编译出来的二进制要确保能被 libpcap 的 configure 找到，否则 configure 会报 “lex not found”。

BISON_VER="${BISON_VER:-3.8.2}" FLEX_VER="${FLEX_VER:-2.6.4}" # 编译 bison cd "$BUILD_DIR" tar -xf "$SRC_DIR/bison-${BISON_VER}.tar.xz" cd "bison-${BISON_VER}" ./configure --prefix="$PREFIX" > "$LOG_DIR/bison-configure.log" 2>&1 make -j"$JOBS" > "$LOG_DIR/bison-make.log" 2>&1 make install > "$LOG_DIR/bison-install.log" 2>&1 # 编译 flex cd "$BUILD_DIR" tar -xf "$SRC_DIR/flex-${FLEX_VER}.tar.gz" cd "flex-${FLEX_VER}" ./configure --prefix="$PREFIX" > "$LOG_DIR/flex-configure.log" 2>&1 make -j"$JOBS" > "$LOG_DIR/flex-make.log" 2>&1 make install > "$LOG_DIR/flex-install.log" 2>&1 # 导出 LEX/YACC，libpcap 的 configure 会读取这两个变量 export LEX="$PREFIX/bin/flex" export YACC="$PREFIX/bin/bison -y"

LEX和YACC这两个环境变量是 libpcap configure 脚本认的。有些版本的 configure 只认flex和bison命令名，不认变量，所以 PATH 也要保证$PREFIX/bin在最前面。bison -y里的-y是让它兼容 yacc 的输出命名，libpcap 的部分构建规则会按 yacc 的约定找y.tab.c。

3.4 编 gcc：把 gmp、mpfr、mpc 这三个数学库提前摆平

gcc 是整条链里最重的一步，也是最容易在离线环境翻车的一步。源码编译 gcc 需要 gmp、mpfr、mpc，官方推荐的contrib/download_prerequisites在断网环境下不可用，必须提前把三个源码包放进 gcc 目录，或者用--with-*参数指向已装好的库。

GCC_VER="${GCC_VER:-9.5.0}" cd "$BUILD_DIR" tar -xf "$SRC_DIR/gcc-${GCC_VER}.tar.xz" cd "gcc-${GCC_VER}" # 离线方案一：把 gmp/mpfr/mpc 源码包放进 gcc 目录， # download_prerequisites 检测到文件已存在会跳过下载 # 需要提前放置：gmp-6.2.1.tar.bz2、mpfr-4.1.0.tar.bz2、mpc-1.2.1.tar.gz # 离线方案二：如果系统已有这三个库，直接指定路径 # ./configure --with-gmp=/usr --with-mpfr=/usr --with-mpc=/usr ./configure \ --prefix="$PREFIX" \ --disable-multilib \ --enable-languages=c,c++ \ --disable-bootstrap \ > "$LOG_DIR/gcc-configure.log" 2>&1 make -j"$JOBS" > "$LOG_DIR/gcc-make.log" 2>&1 make install > "$LOG_DIR/gcc-install.log" 2>&1

--disable-multilib只生成当前架构的库，减少编译量；--enable-languages=c,c++只编 C 和 C++ 前端，libpcap 用不到 Fortran、Go 这些；--disable-bootstrap跳过三阶段自举，编译时间能砍掉一大半，代价是编译器自身的优化验证少一轮，离线应急场景可以接受。如果目标机内存小于 4GB，把JOBS调到 2 甚至 1，否则 gcc 的某些编译单元会把内存吃满，表现为 make 被 OOM killer 杀掉，日志里只留下一行 “Killed”。

gcc 装完后，$PREFIX/bin/gcc就是新编译器。后续编 libpcap 时，要么把$PREFIX/bin放在 PATH 最前，要么在 configure 里显式指定CC="$PREFIX/bin/gcc"。

3.5 编 libpcap：静态库优先，动态库按需

libpcap 的 configure 参数不多，关键是决定静态库还是动态库。离线环境我一般两个都编，静态库给独立小程序用，动态库给需要共享的场景用。

LIBPCAP_VER="${LIBPCAP_VER:-1.10.4}" cd "$BUILD_DIR" tar -xf "$SRC_DIR/libpcap-${LIBPCAP_VER}.tar.gz" cd "libpcap-${LIBPCAP_VER}" CC="$PREFIX/bin/gcc" \ ./configure \ --prefix="$PREFIX" \ --disable-shared \ --enable-static \ > "$LOG_DIR/libpcap-configure.log" 2>&1 make -j"$JOBS" > "$LOG_DIR/libpcap-make.log" 2>&1 make install > "$LOG_DIR/libpcap-install.log" 2>&1

CC显式指向新 gcc，避免脚本里 PATH 被其他逻辑改乱。--disable-shared --enable-static生成libpcap.a，适合静态链接到分析工具里，带到其他机器上不用再拷 so。如果业务侧需要动态库，把这两个参数换成--enable-shared --disable-static再跑一次，或者干脆两个都开。安装完成后，$PREFIX/lib下应该有libpcap.a、libpcap.so（如果编了动态库），$PREFIX/include下有pcap/pcap.h，$PREFIX/bin下有pcap-config。

4. 避坑与排查：离线编译链路上五个高频翻车点

4.1 gcc 编译报缺 GMP/MPFR/MPC

现象：gcc 的 configure 阶段报Building GCC requires GMP 4.2+, MPFR 3.1.0+ and MPC 0.8.0+，或者 make 阶段报找不到gmp.h。

原因：离线环境跑了contrib/download_prerequisites但下载失败，或者根本没放三个数学库的源码包，configure 检测不到。

解决：提前把 gmp、mpfr、mpc 的 tar 包放进 gcc 源码根目录，再跑 download_prerequisites（它会跳过已存在的文件）；或者用--with-gmp=、--with-mpfr=、--with-mpc=指向系统里已有的库。注意三个库的版本要满足 gcc 的最低要求，太老的 gmp 会在链接阶段报符号缺失。

4.2 bison 或 flex 编译时报 m4 相关错误

现象：bison 的 configure 报m4: command not found，或者 make 阶段报宏展开失败。

原因：PATH 里没有新装的 m4，或者系统 m4 版本过老（比如 1.4.16 以下），bison 的构建规则用了新版本才支持的宏写法。

解决：确认$PREFIX/bin在 PATH 最前面，hash -r清缓存后再试；如果系统 m4 太老且无法替换，把 m4 编到独立前缀后用M4="$PREFIX/bin/m4" ./configure显式指定。

4.3 libpcap configure 报找不到 lex/yacc

现象：./configure输出checking for flex... no、checking for bison... no，随后 make 阶段报scanner.c: No such file or directory。

原因：libpcap 从 git 构建或者源码包被裁剪过，预生成的 scanner.c/grammar.c 不存在，configure 又没找到 flex/bison。

解决：先确认$PREFIX/bin/flex和$PREFIX/bin/bison存在且在 PATH 里；再导出LEX、YACC环境变量；如果用的是 release tarball 且不需要重新生成解析器，检查源码目录里是否本来就有 scanner.c，有的话 configure 会跳过 flex/bison 检测。

4.4 安装后程序运行报找不到 libpcap.so

现象：编译链接都通过，运行时报error while loading shared libraries: libpcap.so.1: cannot open shared object file。

原因：安装前缀是/opt/offline-stack/prefix，这个路径不在系统默认的库搜索路径里，动态链接器找不到 so。

解决：三种方式选一种——把$PREFIX/lib写进/etc/ld.so.conf.d/offline-stack.conf后跑ldconfig；或者在编译时加-Wl,-rpath,$PREFIX/lib把路径嵌进二进制；或者用静态库libpcap.a链接，彻底绕开运行时查找。离线环境我一般优先静态链接，少一个运行时依赖就少一个故障点。

4.5 gcc 编译中途被 Killed 或卡死

现象：make 跑到某个文件时进程消失，日志里只有Killed，或者编译时间异常长。

原因：并行度太高导致内存不足，OOM killer 杀掉编译进程；或者磁盘空间不够，临时文件写不进去。

解决：把JOBS降到 2 或 1，重新跑 make；用df -h确认$BUILD_DIR所在分区剩余空间大于 5GB；如果之前中断过，先make clean再编，避免半成品目标文件干扰。这几条是我踩过的血泪经验，尤其是 OOM 那条，日志里不会明说内存不够，只会看到一个孤零零的 Killed。

5. 验证与进阶：用静态链接和 pcap 回放确认这套工具链真的能用

装完不等于能用。我一般会写一个最小验证程序，直接调用 libpcap 的离线读取接口，把编译、链接、运行三个阶段一次跑通。下面这段代码用pcap_open_offline打开一个 pcap 文件，打印文件头和包数量，不依赖网卡，适合离线环境验证。

/* pcap_check.c：验证 libpcap 静态链接和 pcap 文件读取 */ #include <stdio.h> #include <pcap/pcap.h> int main(int argc, char **argv) { if (argc < 2) { fprintf(stderr, "用法: %s <file.pcap>\n", argv[0]); return 1; } char errbuf[PCAP_ERRBUF_SIZE]; /* 离线打开，不碰网卡 */ pcap_t *handle = pcap_open_offline(argv[1], errbuf); if (handle == NULL) { fprintf(stderr, "打开失败: %s\n", errbuf); return 2; } int linktype = pcap_datalink(handle); printf("链路类型: %d\n", linktype); struct pcap_pkthdr *hdr; const u_char *pkt; int count = 0; int rc; /* 逐包读取，rc=0 表示还有包，-2 表示读完 */ while ((rc = pcap_next_ex(handle, &hdr, &pkt)) == 1) { count++; } printf("包数量: %d\n", count); pcap_close(handle); return rc == -2 ? 0 : 3; }

编译命令显式指定头文件和静态库路径：

$PREFIX/bin/gcc -O2 pcap_check.c -o pcap_check \ -I"$PREFIX/include" \ -L"$PREFIX/lib" \ -lpcap

-I指向新装的头文件目录，-L指向库目录，-lpcap让链接器找libpcap.a。如果之前编了动态库且优先链接了 so，用-Wl,-Bstatic -lpcap -Wl,-Bdynamic强制静态链接。编译完成后用ldd pcap_check检查，静态链接的结果里不应该出现 libpcap.so；如果出现了，说明链接顺序或者库类型不对。

运行验证需要一个现成的 pcap 文件。没有的话可以用 tcpdump 在另一台机器上抓几个包，或者用 libpcap 自带的测试用例。./pcap_check sample.pcap输出链路类型和包数量，数字对得上就说明库和头文件是配套的。再跑一次pcap-config --libs和pcap-config --cflags，确认输出的路径都指向$PREFIX，而不是系统旧版本。

进阶一点的做法是把这套验证写进安装脚本末尾，作为--verify阶段自动执行：脚本自己生成一个最小 pcap 文件（写死几个字节的全局头和包记录），编译验证程序，跑一遍，失败就回滚安装目录。从那以后我每次做离线工具链交付，都强制走一遍这个自检，不再靠“make install 没报错”来判断成功。希望帮到你。

本文还有配套的精品资源，点击获取