简介：面向需要在Unix/Linux平台完成libpcap部署与网络抓包环境搭建的开发者、运维及网络安全学习者，这份离线安装资料把gcc、m4、bison、flex等编译依赖与libpcap源码整合为可自动执行的安装方案，重点解决内网或无外网环境下依赖缺失、编译链路繁琐、手工逐步安装易出错的问题。包体共2个文件，包含1个tar源码归档和1个sh安装脚本，整体约43.29MB，脚本负责串联依赖与主库的安装流程，tar包集中承载所需源码，减少逐项搜集与版本匹配成本。已有1041人学习下载，说明其在离线部署场景中具有一定参考价值。读者可据此快速准备抓包开发环境，理解libpcap数据包捕获、自定义发送、流量采集统计与规则过滤等能力背后的依赖关系，并保留可复用的离线安装脚本与源码包，便于后续重装、迁移或排查编译问题。

1. 又一台连源都连不上的机器：libpcap 离线脚本自动安装到底卡在哪

上周又碰到一台机器，内网隔离，yum 源连不上，gcc是有的但版本很老，m4、bison、flex一个都没有，libpcap的源码包解压出来，./configure跑不到十行就退出了。做 libpcap 离线脚本自动安装（含全部依赖 gcc、m4、bison、flex、libpcap），难点从来不是没有源码包，而是这五个包之间有严格的先后顺序和隐式依赖：先编 libpcap，configure 会告诉你缺 lex/yacc；先编 bison，make 又告诉你找不到 m4；flex 生成的东西还要跟 bison 的版本对上。任何一步顺序错，报错信息都会指向一个看起来毫不相干的地方。这套流程适合内网构建机、纯离线分析机，也适合想把编译链固定在某个版本、不想被系统升级带偏的人。下面按我实际落地的顺序，从版本选择、脚本骨架、参数取舍，一直写到坏了怎么救。

2. 装前清单：gcc 11 + m4 1.4.19 + bison 3.8 + flex 2.6.4 + libpcap 1.10 该按什么顺序堆

动手之前，先把五个包的角色和相互关系理清楚，否则脚本写出来就是一通乱编。机器上的编译环境不干净时，最忌讳“有什么编什么”，因为源码包版本和系统残留的库、头文件、pkg-config文件混在一起，最后装出来的东西自己是能跑的，换台机器就崩。

2.1 五个包各自干什么，版本怎么搭配

先用一张表把链路固定下来。表中的版本线是离线环境里比较省心的组合，实际脚本里我一般把版本号提到文件头做变量，源码包换版本时只改一处。

版本上真正要盯的是 C 标准。bison 3.8 和 flex 2.6.4 的源码都用到了 C99 特性，系统自带 gcc 如果是 4.4 这种级别，编 flex 时会在一堆for循环变量声明上报错。gcc 选 9.x 还是 11.x，主要看 glibc：老系统上 glibc 版本低，强行装 11.x 编出来的二进制在新机器上可能跑不起来，常见做法是跟目标机器 glibc 的主版本对齐，而不是一味追新。m4 1.4.19 基本是唯一选择，1.4.17 以下 bison 会直接拒绝，configure 阶段就告诉你 m4 版本过低。

还有一个容易被忽略的点：libpcap 的官方发布 tar 包里，scanner.c和grammar.c是预生成好一起打包的，所以严格来说，编发布版 libpcap 不一定需要 flex 和 bison。但只要源码包被人清理过、或者从版本库直接导出、或者你需要改过滤表达式语法，这两个工具就必须在场。脚本里把 flex、bison 放进去，是为了让这套环境在“源码不完整”时也能兜住，而不是因为它们每次都一定会被调用到。

2.2 目录规划和编译顺序

目录我习惯这样分，所有产物都不污染系统路径，出问题删目录就能回滚：

# 离线包统一放在 pkgs，解压到 src，构建产物留在各自源码目录 /opt/offline-build/ ├── pkgs/ # 五个 tar.gz 和校验文件 ├── src/ # 解压后的源码树 ├── logs/ # 每个包 configure/make/install 三段日志 └── offline/ # 最终安装前缀，即 PREFIX

编译顺序是 m4 → bison → flex → gcc（可选）→ libpcap。m4 排第一没有争议，bison 的构建过程要调用它。bison 排在 flex 前面，是因为 flex 的部分测试和生成代码需要 yacc 兼容层，先有新 bison 更稳。

gcc 排在后面，这点跟很多人的直觉相反。原因是：升级 gcc 会改变系统默认的cc，如果先把 gcc 换掉，后面的 bison、flex 就是用新编译器编的，而新版本 gcc 的告警更严格，一些老代码在-Werror下会直接编译失败。我一般的做法是先用系统自带 gcc 把 m4、bison、flex 编完装好，确认这三个能跑，再决定要不要动 gcc，最后用最终确定的编译器编 libpcap。

提示：如果机器上连一个能用的 C 编译器都没有，源码安装 gcc 是走不通的，因为 gcc 自身需要一个 C 编译器做自举。这种情况得先用系统安装介质里的 gcc 包补齐基础工具链，再谈源码升级。

2.3 离线包完整性核对与解压

离线环境最大的坑不是编译，是包在拷贝过程中被截断。我见过一次 tar.gz 少了几百字节，解压不报错，configure 阶段报语法错误，查了两个小时。所以脚本第一步永远是校验：

cd /opt/offline-build/pkgs # SHA256SUMS 由打包机生成，跟五个 tar.gz 一起带进离线环境 sha256sum -c SHA256SUMS # 校验通过后再统一解压，-C 指定目标目录，避免源码树散落 for f in m4-1.4.19.tar.gz bison-3.8.2.tar.gz flex-2.6.4.tar.gz \ libpcap-1.10.4.tar.gz gcc-11.4.0.tar.gz; do tar -xzf "$f" -C /opt/offline-build/src done

sha256sum -c会逐行输出 OK 或 FAILED，只要有一条不是 OK，后面全部不要执行。tar -xzf里的-C把解压目标固定到 src 目录，脚本里后续所有路径都基于这个约定，不依赖当前工作目录，这样从 cron 或者别的目录调用脚本都不会跑偏。

3. 离线脚本落地：把五个源码包压成一条命令

脚本的目标很明确：一条命令跑完，中途任何一步失败就停，日志能定位到具体是哪个包的哪个阶段出的问题。手工敲五遍 configure 当然也能装完，但离线机器往往没有第二次机会，第二次进机房可能是一周以后。

3.1 脚本骨架：变量区、日志、失败即停

#!/bin/bash # offline-build.sh —— 五个源码包的离线编译入口 set -euo pipefail PREFIX=/opt/offline-build/offline SRC_DIR=/opt/offline-build/src LOG_DIR=/opt/offline-build/logs JOBS=$(nproc) mkdir -p "$PREFIX" "$LOG_DIR" log() { printf '[%s] %s\n' "$(date +%H:%M:%S)" "$*"; }

set -euo pipefail这三个开关必须一起用：-e让任何一条命令返回非零就退出，-u让引用未定义变量直接报错，-o pipefail保证管道里前一段失败也能被捕获。少了pipefail，./configure | tee log这种写法会把 configure 的失败吞掉，脚本继续往下跑，最后装出来一个半成品。

JOBS=$(nproc)取 CPU 核数，make -j用它。有些老机器nproc返回值很大但内存很小，并行编译 gcc 时会被 OOM killer 干掉，这种机器上我一般手动改成JOBS=$(($(nproc)/2+1))。

3.2 通用编译函数：一个函数吃下五个包

五个包的编译流程高度一致，抽成一个函数，差异用参数传进去：

build_one() { local name=$1; shift # 第一个参数是目录名，其余全部透传给 configure local dir="$SRC_DIR/$name" log "开始 $name" cd "$dir" || { log "目录不存在: $dir"; exit 1; } # 三段日志分开存，出错时直接看对应阶段的文件 ./configure --prefix="$PREFIX" "$@" > "$LOG_DIR/$name.configure.log" 2>&1 make -j"$JOBS" > "$LOG_DIR/$name.make.log" 2>&1 make install > "$LOG_DIR/$name.install.log" 2>&1 log "$name 完成" }

函数体里"$@"是透传参数的写法，调用时写在目录名后面的内容会原样拼到./configure --prefix=...后面，这样每个包的专属开关就不用改函数本身。三段日志分开存是有意的：configure 失败通常是依赖缺失或编译器不可用，make 失败通常是代码问题或内存不足，install 失败通常是权限问题，日志分开能省掉大量翻找时间。

3.3 五个包的实际调用与参数差异

# 让新装的工具优先于系统自带版本，顺序很重要 export PATH="$PREFIX/bin:$PATH" build_one m4-1.4.19 # bison 构建期就要调 m4，显式指定路径作为保险 M4="$PREFIX/bin/m4" build_one bison-3.8.2 --disable-nls # flex 需要能找得到 bison，--with-bison 写死路径，避免拿到系统旧版 M4="$PREFIX/bin/m4" build_one flex-2.6.4 \ --disable-nls --with-bison="$PREFIX/bin/bison" # libpcap 放最后，用前面装好的工具链 build_one libpcap-1.10.4 \ --disable-dbus --disable-bluetooth --disable-rdma --without-libnl

export PATH放在最前面，是因为 bison 的 configure 脚本会用AC_PATH_PROG去找 m4，找不到就直接报错退出。虽然用环境变量M4=也能覆盖，但 PATH 顺序对 flex 找 bison 同样生效，一次设好省事。libpcap 那几个--disable-*是为无外设的服务器准备的，dbus、蓝牙、RDMA 在内网构建机上根本不存在，开着只会让 configure 多一堆探测，某些发行版上还会因为缺头文件直接失败。

如果这台机器确实需要升级 gcc，再追加一段，位置放在 libpcap 之前：

build_one gcc-11.4.0 \ --enable-languages=c,c++ \ --disable-multilib \ --disable-bootstrap \ --with-system-zlib

--enable-languages=c,c++只编需要的语言前端，能省掉一大半编译时间；--disable-multilib关掉 32 位库；--disable-bootstrap只编一遍，不做三阶段自举。这三个开关都是拿时间换速度的取舍，后面第 4 章细说。

3.4 环境变量与动态库路径收尾

装完不收尾，等于没装。/opt/offline-build/offline/lib不在系统默认搜索路径里，程序运行时找不到libpcap.so.1：

# 注册动态库搜索路径，ldconfig 重建缓存后运行时才能找到 so echo "$PREFIX/lib" > /etc/ld.so.conf.d/offline-libpcap.conf ldconfig # 让新装的 pcap-config、bison、flex 对登录用户可见 cat > /etc/profile.d/offline-toolchain.sh <<'EOF' export PATH=/opt/offline-build/offline/bin:$PATH export PKG_CONFIG_PATH=/opt/offline-build/offline/lib/pkgconfig:$PKG_CONFIG_PATH EOF chmod +x /etc/profile.d/offline-toolchain.sh

ld.so.conf.d下的文件会被ldconfig读取，写一个独立文件比直接改/etc/ld.so.conf好回滚，删文件再跑一次ldconfig就干净了。PKG_CONFIG_PATH指向新装的 pkgconfig 目录，是为了让后续编上层程序时pkg-config --cflags libpcap拿到的是新版本的头文件路径，而不是系统里残留的老版本。这两步做完，重新登录一次让 profile 生效，或者直接source /etc/profile.d/offline-toolchain.sh。

4. 参数取舍：bison、flex、gcc、libpcap 的 configure 开关逐个掰

同样的源码，参数不同编出来的东西差别很大。这一章讲的是每个开关为什么要加、不加会怎样，以及在什么场景下应该反过来选。

4.1 gcc：语言前端、自举和多架构的三笔账

--enable-languages=c,c++是最划算的一个开关。默认配置会把 ada、fortran、go、objc 全编一遍，离线构建机根本用不到，白白多花一两个小时。只留 c 和 c++ 足够支撑 m4、bison、flex、libpcap 的编译，上层程序如果不用 c++，甚至可以只留 c。

--disable-bootstrap的取舍更需要说清楚。gcc 默认做三阶段自举：用系统编译器编一个 stage1，用 stage1 编 stage2，再比较 stage2 和 stage3 的产物是否一致。这套流程能验证编译器自身的正确性，代价是编译时间翻三倍。内网构建机上我一般关掉，因为目标只是“得到一个比系统版本新的、能编 libpcap 的编译器”，不需要验证编译器正确性。但如果是给正式产品出工具链，这个开关不能关。

--disable-multilib关掉 32 位库支持。目标机全是 64 位时必关，开着会要求系统里有一套 32 位的 glibc 头文件，离线环境里凑不齐就直接 configure 失败。

真正容易翻车的是 gcc 的三个前置依赖：GMP、MPFR、MPC。官方源码包不包含它们，联网环境可以跑contrib/download_prerequisites自动拉，离线环境没这条路。常见做法是把三个依赖的源码包也带进来，解压后放到 gcc 源码目录下并建软链接，让 gcc 的 configure 就地编译它们：

cd /opt/offline-build/src/gcc-11.4.0 # 三个依赖解压后，在 gcc 源码目录内建同名软链，configure 会自动识别 ln -sfn ../gmp-6.2.1 gmp ln -sfn ../mpfr-4.1.0 mpfr ln -sfn ../mpc-1.2.0 mpc

软链名必须是gmp、mpfr、mpc这三个，gcc 的顶层 configure 是按固定名字查找的。

4.2 bison 与 flex：nls 和交叉引用

--disable-nls关掉国际化支持，也就是不编译 gettext 相关的翻译文件。离线环境里系统自带的 gettext 版本经常和 bison 要求的不匹配，开着 nls 会在 configure 阶段报 gettext 版本过低。关掉不影响任何编译功能，只是报错信息变成英文，对构建机来说完全可以接受。

bison 还有一个隐式依赖要显式化：M4="$PREFIX/bin/m4"。bison 的 configure 会去 PATH 里找 m4，如果系统里那个老版本 m4 排在前面，编译能过，但生成的解析器可能有问题，表现出来是运行时段错误或者语法分析结果不对。写死路径这个动作看着多余，实际省掉的是排查玄学问题的时间。

flex 的--with-bison同理。flex 的测试套件和yylex相关代码生成会调用 bison，如果拿到系统里那个更老的 bison，产出的代码可能和头文件声明不匹配，链接时报conflicting types for 'yylex'。这个报错极具迷惑性，很多人会去查自己的.l文件，其实是工具版本串了。

4.3 libpcap：抓包后端和可选特性的开关

libpcap 1.10 系列的 configure 选项最多，取舍标准是目标机有没有对应硬件：

--without-libnl需要单独解释。开着它时 libpcap 会用 libnl 枚举 802.11 接口，机器上没有 libnl 开发包就会在 configure 阶段降级并打一条 warning，功能退化成读/proc/net/dev。这条 warning 不影响编译成功，但会让日志里多出一条看起来像错误的信息，关掉更干净。

如果是给容器或者精简系统编，还要考虑--disable-shared --enable-static，只出静态库，省掉运行时找 so 的麻烦。

4.4 共享库还是静态库

默认两边都编，make install后lib下同时有.so和.a。我一般保留默认，因为上层程序有的用动态链接有的用静态链接。但如果目标机器上已经存在系统自带的 libpcap，动态链接会有版本串用风险：程序运行时通过ld.so找到的可能是/usr/lib下的老版本。

判断方法很简单，装完后跑一次ldd看实际链接到哪个路径。如果发现指向系统路径，要么调整ld.so.conf的顺序，把/opt/offline-build/offline/lib放前面，要么在编译上层程序时加-Wl,-rpath,/opt/offline-build/offline/lib把路径写死进二进制。后者更稳，代价是二进制不能随便搬机器。

5. 踩坑排查：这五类报错我每次离线编译都会先防一遍

下面五条是按出现频率排的，每条都给出我实际遇到的现象、原因和解决办法。离线环境的排查成本极高，能提前防住就别等出事再查。

5.1 报错C compiler cannot create executables

现象：m4 的 configure 跑到一半退出，config.log末尾是这句，前面还有一堆conftest.c相关的内容。

原因：系统里没有可用的 C 编译器，或者 gcc 装了但缺 libc 开发头文件。第二种更常见，gcc --version有输出，但编译任何东西都失败。

解决：先单独验证编译器可用性，再跑脚本：

# 用最小用例验证编译器能产出可执行文件 printf 'int main(void){return 0;}\n' > /tmp/t.c gcc /tmp/t.c -o /tmp/t && /tmp/t && echo "编译器正常"

这条命令失败就去补 glibc-devel 或对应的开发包，别在脚本里反复试。config.log里搜error关键字比看屏幕输出靠谱，屏幕上的报错往往只是最后一行。

5.2 bison 编译时报m4: command not found或m4 version too old

现象：bison 的 make 阶段中断，提示找不到 m4；或者 configure 阶段明确说 m4 版本低于 1.4.6。

原因：m4 装到了非标准前缀但没进 PATH，或者 PATH 里排前面的是系统老版本 m4。

解决：确认$PREFIX/bin/m4 --version输出正常，然后在编译 bison 时显式传M4="$PREFIX/bin/m4"。同时检查echo $PATH，$PREFIX/bin必须在最前面，不能是追加在末尾。

5.3 链接报conflicting types for 'yylex'

现象：flex 编译完成，但编依赖它的程序时链接失败，报yylex类型冲突。

原因：flex 生成代码时调用的是系统里的老 bison，和新装的 bison 头文件声明不一致。

解决：flex 的 configure 加--with-bison="$PREFIX/bin/bison"，并确认 PATH 顺序。已经编坏的需要make distclean后重新 configure，直接make不会重新生成。

5.4 libpcap configure 报Neither flex nor lex was found

现象：libpcap 的 configure 直接失败，提示找不到 flex 或 lex。

原因：源码包不是官方发布的 tar 包，scanner.c和grammar.c被清理掉了，configure 检测到需要现场生成扫描器。

解决：先确认 flex 和 bison 确实装好且在 PATH 里，跑flex --version和bison --version验证。如果工具在但 configure 还是找不到，看config.log里它是怎么探测的，常见情况是探测时用了绝对路径/usr/bin/flex。这种情况下换回官方 tar 包最省事，因为发布包里预生成的文件是全的，根本不需要这两个工具。

5.5 运行时报libpcap.so.1: cannot open shared object file

现象：编译链接全部成功，程序一跑就报找不到共享库。

原因：装到了非标准前缀，ld.so缓存里没有这个路径。或者是ldconfig跑在安装之前。

解决：按 3.4 节写/etc/ld.so.conf.d/下的配置文件再ldconfig，用ldconfig -p | grep pcap确认路径已经进缓存。程序如果还要分发给别的机器，编译时加-Wl,-rpath把路径写进去，或者干脆静态链接。

6. 装完怎么验证：三条命令加一个 C 小程序，确认 libpcap 真能抓包

装完不验证，等于给自己留了个定时炸弹。make install成功只能说明文件被复制过去了，不能说明这套 gcc、m4、bison、flex、libpcap 的链路是通的。我一般按从轻到重的顺序验三层：工具版本、库自检、真实调用。

第一层看版本，一条命令扫全部：

for t in gcc m4 bison flex; do printf '%-6s ' "$t"; $t --version | head -1; done pcap-config --version

期望输出里，gcc 显示的是最终生效的那个版本，如果升级过 gcc 但这里还是系统老版本，说明 PATH 没生效或者装到了别的前缀。pcap-config --version输出 1.10.4 就对了，这个脚本是 libpcap 装出来的，它存在本身就说明 install 阶段没出问题。

第二层用pcap-config验证编译链接参数是否自洽：

# --cflags 给头文件路径，--libs 给链接参数，两者必须指向同一个前缀 pcap-config --cflags pcap-config --libs ldconfig -p | grep libpcap

输出里如果--cflags是-I/opt/offline-build/offline/include，--libs是-L/opt/offline-build/offline/lib -lpcap，而ldconfig -p里也有同一个路径，三层就对上了。三者只要有一处指向/usr，就说明系统里有残留版本在抢戏。

第三层是真实调用，写个最小程序把网卡列出来：

/* pcap_probe.c —— 验证 libpcap 能枚举网卡，不实际抓包，权限要求低 */ #include <pcap/pcap.h> #include <stdio.h> int main(void) { pcap_if_t *devs = NULL, *d; char errbuf[PCAP_ERRBUF_SIZE]; /* pcap_findalldevs 替代已废弃的 pcap_lookupdev，返回链表需手动释放 */ if (pcap_findalldevs(&devs, errbuf) == -1) { fprintf(stderr, "枚举失败: %s\n", errbuf); return 1; } for (d = devs; d != NULL; d = d->next) { printf("%-12s %s\n", d->name, d->description ? d->description : "(无描述)"); } pcap_freealldevs(devs); return 0; }

编译和运行：

# 用 pcap-config 输出的参数编译，验证 cflags 与 libs 是否配套 gcc pcap_probe.c -o pcap_probe $(pcap-config --cflags --libs) ./pcap_probe

能列出eth0、lo这类网卡名，就说明动态库加载、头文件路径、API 调用全通了。这一步不需要 root 权限，比直接开抓包安全得多。如果要进一步验证抓包能力，再写一个pcap_open_live的用例，用 root 或给二进制加CAP_NET_RAW能力，报You don't have permission to capture时先查权限而不是怀疑安装。

血泪经验是：这三层里任何一层没跑，都别急着把机器交出去。我吃过一次亏，make install全绿，交付后对方跑程序报找不到 so，回头查是ldconfig在安装之前执行的，缓存里根本没有新路径。从那以后我每次装完都强制走一遍ldconfig -p | grep，再编一个最小 C 程序跑通，确认这条链路是真的活了我才收工。希望帮到你。

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