libpcap 离线源码编译：依赖链与避坑指南

简介：面向在Unix/Linux平台进行网络数据包捕获、流量采集与协议分析开发的工程师及学习者，这份libpcap离线安装材料针对内网、无外网或依赖缺失环境下的编译安装难题，提供脚本化的一站式部署方案。压缩包仅含2个文件，由1个tar归档和1个sh安装脚本组成，整体约43.29MB，tar包集中存放gcc、m4、bison、flex、libpcap等源码依赖，sh脚本负责按序解压、编译与安装，减少手工处理依赖版本和编译参数的成本。资源围绕libpcap的抓包、原始数据包发送、流量统计和规则过滤等能力组织，适合需要快速搭建底层抓包开发环境、复现实验或排查编译问题的读者参考。目前已有1041人学习下载，可作为离线部署libpcap及其工具链的实用脚本与依赖合集。

1. 断网机器上装 libpcap：为什么绕不开 gcc 源码编译

某实验室有一台内网分析机，上面跑着一个流量采集 Demo，机器不通外网，系统自带的 libpcap 版本偏老，头文件里连pcap_set_immediate_mode这个接口都找不到。想用包管理器补，源指向的是一个空目录；想拷现成的二进制包进去，依赖一查又是一长串，版本还对不上。这种环境里最稳的路子，是把 gcc、m4、bison、flex、libpcap 五个源码包一次性带进去，用脚本按依赖顺序编译安装。下面就把 m4、gcc、bison、flex 到 libpcap 这条离线链路拆开：每个包为什么排在这个位置、configure 要盯哪几个参数、装完怎么验证、以及我在几台机器上翻过的车。

2. 依赖链拆解：m4、gcc、bison、flex、libpcap 谁在等谁

2.1 五个源码包各自干什么，次序为什么不能乱

先看每个包的角色。m4 是一个宏处理器，gcc 源码树里的configure脚本由 autoconf 生成，展开宏的时候要调用 m4；bison 在生成语法分析器骨架文件时同样会调用 m4。gcc 是 C/C++ 编译器，后面 bison、flex、libpcap 的编译都靠它。bison 把.y语法文件转成 C 代码，libpcap 的grammar.y需要它。flex 把.l词法文件转成 C 代码，libpcap 的scanner.l需要它。libpcap 是最终目标，一个用户态抓包库，上层程序通过它打开网卡、设置过滤规则、读数据包。

依赖关系理清之后，编译顺序就固定了：m4 → gcc → bison → flex → libpcap。bison 和 flex 之间没有相互依赖，谁先谁后都行，但两个都得排在 gcc 后面、libpcap 前面。

有人会问，系统里明明有 gcc，为什么还要从源码再编一个。原因在于版本。老发行版自带的 gcc 常常是 4.8 这一档，用它去编较新的 libpcap，会在 C99 特性上卡住，报一堆unknown type name或者for loop initial declarations are only allowed in C99 mode。而想编一个新版 gcc，又必须先有一个能用的 m4。整个链条是环环相扣的，跳过任何一环，后面都会以某种看起来莫名其妙的方式失败。

还有一层现实约束：目标机器的 glibc 版本决定了新编出来的 gcc 能不能在上面跑。如果构建机和目标机不是同一台，最好在目标机上编，或者至少保证两边的 glibc 大版本一致。跨大版本搬运编译产物，是离线部署里翻车率最高的操作之一。

2.2 离线包的目录怎么组织

脚本要能一键跑通，前提是文件摆放有规矩。我一般把整个离线包做成这样一个结构，拷进目标机后直接解压就能用：

把安装前缀统一到/opt/offline-pcap而不是直接装进/usr，有两个好处。一是不会覆盖系统自带的旧版本，出问题时把目录一删就干净了；二是后面配PATH、LD_LIBRARY_PATH、PKG_CONFIG_PATH的时候，三个变量指向同一个根，路径管理简单。

源码包的文件名里带版本号，脚本里不要写死。常见做法是用通配符匹配，或者把版本号抽成变量放在脚本头部：

#!/usr/bin/env bash set -euo pipefail # 版本号集中在这里，换包时只改这一处 M4_VER="1.4.19" GCC_VER="9.5.0" BISON_VER="3.8.2" FLEX_VER="2.6.4" PCAP_VER="1.10.4" PREFIX="/opt/offline-pcap" ROOT="$(cd "$(dirname "$0")" && pwd)" SRC="$ROOT/src" BUILD="$ROOT/build" LOGS="$ROOT/logs" mkdir -p "$BUILD" "$LOGS" "$PREFIX" # 统一的前置环境，后续每个包都继承 export PATH="$PREFIX/bin:$PATH" export LD_LIBRARY_PATH="$PREFIX/lib:$PREFIX/lib64:${LD_LIBRARY_PATH:-}"

这段的作用是把所有可变因素集中到头部五个变量里。set -euo pipefail保证任何一步失败就整体退出，不会出现「前面失败了但脚本继续往下跑、最后装了个半成品」的情况。ROOT用脚本自身位置推算，这样整个目录挪到哪都能跑。PATH和LD_LIBRARY_PATH在脚本最开头就设好，后面每个包的configure和make都能吃到，不用每段重复写。

2.3 版本选型的三条硬约束

版本不是随便挑最新就行，有三条约束会直接决定成败。

第一条是 glibc。gcc 编出来的二进制依赖构建机的 glibc 符号版本，目标机 glibc 低于构建机时，运行会报GLIBC_2.xx not found。动手前先在目标机上查一下：

# 三条命令确认基础环境，输出贴到日志里备查 ldd --version | head -n1 # glibc 版本，决定 gcc 能不能跑 uname -r # 内核版本，影响 libpcap 的抓包后端 gcc --version 2>/dev/null | head -n1 || echo "no system gcc" m4 --version 2>/dev/null | head -n1 || echo "no system m4"

第二条是 bison 必须是 3.x。libpcap 的语法文件用了较新的 bison 特性，用 2.7 这种老版本去生成，会在编译期报syntax error, unexpected ...，而且报错位置在自动生成的 C 文件里，很难一眼看出根因。所以 bison 一定要用离线包里自带的那份。

第三条是 gcc 要支持 C99 及以上。libpcap 较新版本大量使用了//注释、混合声明、stdint.h这些特性。如果只能用系统老 gcc，就得回头找更老的 libpcap 版本，这又会牵出别的兼容问题，不如一开始就把 gcc 编好。

3. 从零编 gcc：configure 参数与耗时的真实账单

3.1 解压与前置依赖自检

gcc 的源码包解开之后，官方文档会让你跑./contrib/download_prerequisites去拉 gmp、mpfr、mpc 三个数学库。这个脚本内部是wget，离线环境直接卡死。所以这一步必须提前处理，有两条路可走。

第一条路是目标机上已经装了gmp-devel、mpfr-devel、mpc-devel，那就在 configure 时用--with-gmp、--with-mpfr、--with-mpc显式指过去。第二条路是这三个包也没有，那就得把它们的源码包也放进src/，解开后放到 gcc 源码目录下，用软链接对上 gcc 期望的目录名：

cd "$BUILD" tar -xf "$SRC/gcc-${GCC_VER}.tar.gz" # 三个数学库的源码包手工放到位，替代在线下载脚本 tar -xf "$SRC/gmp-6.2.1.tar.xz" -C "gcc-${GCC_VER}" tar -xf "$SRC/mpfr-4.1.0.tar.xz" -C "gcc-${GCC_VER}" tar -xf "$SRC/mpc-1.2.1.tar.gz" -C "gcc-${GCC_VER}" # gcc 的构建系统认的是不带版本号的目录名 ln -sfn "gmp-6.2.1" "gcc-${GCC_VER}/gmp" ln -sfn "mpfr-4.1.0" "gcc-${GCC_VER}/mpfr" ln -sfn "mpc-1.2.1" "gcc-${GCC_VER}/mpc"

这里的关键是软链接的名字必须是gmp、mpfr、mpc，gcc 的顶层configure就是按这三个固定名字去找源码目录的。版本号写在链接目标里，链接名保持干净。三个包都放好之后，configure阶段就不会再去联网。

动手之前还要确认一件事：磁盘空间。gcc 源码解开大约 1G，构建目录生成的目标文件加上最终安装产物，整体会到 6 到 8G。df -h看一眼，剩不到 10G 就先清一清，不然编到一半No space left on device，前面的时间全白费。

3.2 configure 参数逐项说明

gcc 的 configure 参数很多，离线场景下真正需要动的就下面这几个：

cd "$BUILD/gcc-${GCC_VER}" mkdir -p build && cd build ../configure \ --prefix="$PREFIX" \ --enable-languages=c,c++ \ --disable-multilib \ --disable-bootstrap \ --with-system-zlib \ --disable-libsanitizer \ 2>&1 | tee "$LOGS/gcc-configure.log"

--prefix指向统一的安装根，和前面 m4 装的位置保持一致。--enable-languages=c,c++只编 C 和 C++ 两个前端，Fortran、Go、Ada 这些完全不碰，能省掉一半以上的编译时间。--disable-multilib让 64 位机器只产出 64 位库，不生成 32 位兼容版本，同样是为了省时间。

--disable-bootstrap是争议最大的一个。默认情况下 gcc 会用三步引导：先用系统编译器编一个 stage1，再用 stage1 编 stage2，最后用 stage2 编 stage3，然后比较 stage2 和 stage3 的产物是否一致，以此验证编译器自身的正确性。这套流程走完要两三个小时。关掉之后只编一遍，二三十分钟能出结果，但代价是失去了自校验，理论上生成物可能存在隐蔽错误。离线应急场景下我一般会关，但如果是长期使用的构建机，这个参数建议保留默认，让自举跑完。

--with-system-zlib表示用系统已有的 zlib，不再单独编一份。--disable-libsanitizer关掉 AddressSanitizer 这类运行时库，它们在离线环境里编译失败率不低，而且抓包工具链用不上，直接关掉省事。

3.3 make 与 install：并行度、耗时和失败排查

configure 通过之后就是编译。这里有个血泪经验：-j的数值不要直接给nproc。gcc 的单个编译进程峰值能吃到 1 到 2G 内存，16 核机器上make -j16很容易触发 OOM Killer，表现是某个cc1进程突然消失，make 报一个看不懂的错误然后退出。稳妥的算法是按内存给并行度，一般取nproc的一半：

cd "$BUILD/gcc-${GCC_VER}/build" # 并行度按 CPU 核数和内存综合给，避免 OOM JOBS=$(( $(nproc) / 2 )) [ "$JOBS" -lt 1 ] && JOBS=1 make -j"$JOBS" 2>&1 | tee "$LOGS/gcc-make.log" make install 2>&1 | tee "$LOGS/gcc-install.log"

tee把输出同时写到屏幕和日志文件，编的过程中能看到进度，失败之后又能回头翻。gcc 的 make 输出非常长，几万行很正常，出了问题不要从头读，直接搜关键字：

# 失败后先定位错误行，再看上下文 grep -n "error:" "$LOGS/gcc-make.log" | head -n 20

最常见的错误是cannot find gmp.h或者mpfr.h: No such file or directory，说明 3.1 里那三个软链接没建对，或者--with-gmp的路径指错了。第二常见的是内存不足导致的Killed，把JOBS调小重来即可。第三常见的是磁盘满，No space left on device，这个只能清空间。

装完之后验证一下：

"$PREFIX/bin/gcc" --version | head -n1 "$PREFIX/bin/gcc" -dumpmachine

第二条命令输出目标平台三元组，比如x86_64-pc-linux-gnu，用来确认编出来的编译器架构和预期一致。如果这里输出的是 32 位三元组，说明 multilib 没关干净，后面编 64 位库会出问题。

4. m4、bison、flex 三件套：串联编译与路径隔离

4.1 m4 为什么必须排在最前面

m4 是整个链条的第一环，但它经常被忽略，因为大多数系统自带 m4，看起来不需要单独处理。问题出在版本上：较新的 autoconf 生成的configure脚本会用到 m4 1.4.16 之后才有的特性，系统 m4 低于这个版本时，configure跑到一半会报m4: unrecognized option或者宏展开结果异常，最终表现是某个检查项莫名其妙地失败。

所以脚本的第一步就是把 m4 编好并前置到PATH：

cd "$BUILD" tar -xf "$SRC/m4-${M4_VER}.tar.gz" cd "m4-${M4_VER}" ./configure --prefix="$PREFIX" 2>&1 | tee "$LOGS/m4-configure.log" make -j"$(nproc)" 2>&1 | tee "$LOGS/m4-make.log" make install 2>&1 | tee "$LOGS/m4-install.log" # 让后续所有包都用这一份 m4 export PATH="$PREFIX/bin:$PATH" hash -r m4 --version | head -n1

hash -r这一句容易被漏掉。bash 会缓存命令路径，前面如果已经调用过系统 m4，改完PATH之后不加hash -r，它还是走缓存里的旧路径。表现就是which m4显示的是新路径，但实际执行的是旧的，非常玄学。加上这一句，缓存清掉，后面的调用才会真正生效。

4.2 bison：把 M4 路径显式传进去

bison 的configure会去探测 m4，但它探测的方式是看PATH里第一个 m4。如果前面PATH设置正确，这一步通常没问题。但在某些 shell 环境下，configure探测到的路径和实际执行的不一致，生成的Makefile里就写死了错误的 m4 路径，编到生成骨架文件那一步才报错。

避免这种不确定性的办法是显式传参：

cd "$BUILD" tar -xf "$SRC/bison-${BISON_VER}.tar.gz" cd "bison-${BISON_VER}" # M4 环境变量直接指定，绕开 configure 的自动探测 ./configure \ --prefix="$PREFIX" \ M4="$PREFIX/bin/m4" \ 2>&1 | tee "$LOGS/bison-configure.log" make -j"$(nproc)" 2>&1 | tee "$LOGS/bison-make.log" make install 2>&1 | tee "$LOGS/bison-install.log" bison --version | head -n1

M4=是 bison 的configure明确认的环境变量，写在这里比依赖PATH更确定。装完之后bison --version输出的第一行会带版本号，确认是 3.x 就对了。

4.3 flex 与动态库路径固化

flex 相对独立，它不依赖 m4，也不依赖 bison，编译过程最省心。但它装出来的可执行文件会链接libfl，而libfl装在$PREFIX/lib下，不在系统默认的库搜索路径里。如果只设了LD_LIBRARY_PATH，换个 shell 或者换个用户跑就失效。

稳妥做法是写进ld.so.conf.d，让动态链接器自己认：

cd "$BUILD" tar -xf "$SRC/flex-${FLEX_VER}.tar.gz" cd "flex-${FLEX_VER}" ./configure --prefix="$PREFIX" 2>&1 | tee "$LOGS/flex-configure.log" make -j"$(nproc)" 2>&1 | tee "$LOGS/flex-make.log" make install 2>&1 | tee "$LOGS/flex-install.log" # 固化库路径，避免只靠临时环境变量 echo "$PREFIX/lib" > /etc/ld.so.conf.d/offline-pcap.conf echo "$PREFIX/lib64" >> /etc/ld.so.conf.d/offline-pcap.conf ldconfig flex --version

ldconfig执行完之后，动态链接器就能在任意 shell 里找到$PREFIX/lib下的库，不再依赖LD_LIBRARY_PATH。这一步在离线部署里很关键，因为最终跑抓包程序的可能是另一个用户、另一个服务，环境变量传不过去。

4.4 三件套版本自检

三个包都装完之后，做一次集中自检，确认PATH生效、版本正确、没有指向系统旧版本：

# which 和 version 必须双双对上，缺一不可 for c in m4 bison flex; do printf "%-6s -> %s\n" "$c" "$(command -v "$c")" done m4 --version | head -n1 bison --version | head -n1 flex --version

command -v输出的是实际会被执行的路径。如果这里显示/usr/bin/bison而不是$PREFIX/bin/bison，说明PATH没有真正生效，后面编 libpcap 时就会用错版本。这种情况在第 6 章会展开说是怎么翻车的。

5. libpcap 编译与验证：抓包 Demo 真正跑起来

5.1 configure 关键开关

前面四个包都是为这一步做铺垫。libpcap 的configure会去检查一堆可选依赖，离线环境里这些依赖大多不存在，如果不显式关掉，configure会花很长时间探测，最后还可能因为某个探测失败而中断。

cd "$BUILD" tar -xf "$SRC/libpcap-${PCAP_VER}.tar.gz" cd "libpcap-${PCAP_VER}" ./configure \ --prefix="$PREFIX" \ --with-pcap=linux \ --disable-shared \ --without-libnl \ --without-dbus \ 2>&1 | tee "$LOGS/libpcap-configure.log"

--with-pcap=linux指定抓包后端为 Linux 的AF_PACKET。这个后端不依赖libnl，是 Linux 下最直接的选择。--without-libnl和--without-dbus是把两个常见的外部依赖显式关掉，前者用于 netlink 相关的高级特性，后者用于系统总线上的设备侦测，抓包核心功能都不需要它们。

--disable-shared只产出静态库。静态链接的好处是最终程序拷到别的机器上不用带.so，部署简单；代价是程序体积变大，而且如果上层程序用dlopen动态加载 libpcap，静态库就不适用。这个要根据实际用途选，我一般离线部署选静态，省去库路径的麻烦。

5.2 编译安装与 pkg-config 验证

make -j"$(nproc)" 2>&1 | tee "$LOGS/libpcap-make.log" make install 2>&1 | tee "$LOGS/libpcap-install.log" # 确认头文件和库都到位 ls "$PREFIX/include/pcap/pcap.h" ls "$PREFIX/lib/libpcap".*

装完之后，用pkg-config验证一下编译参数能不能正确取出来。这一步能提前暴露路径配置问题：

export PKG_CONFIG_PATH="$PREFIX/lib/pkgconfig" pkg-config --cflags --libs libpcap

正常输出类似-I/opt/offline-pcap/include -L/opt/offline-pcap/lib -lpcap。如果报Package libpcap was not found，说明PKG_CONFIG_PATH没设对，或者安装时pkgconfig目录没生成。后者通常是因为configure阶段缺了pkg-config工具本身，回到系统里补一个再重新configure即可。

5.3 最小抓包程序验证

库装好了不代表能用，得写个最小程序跑一遍才知道。下面这段代码只做一件事：枚举本机所有网卡并打印名字。能正常输出，说明头文件、库链接、设备权限三条链路都通了。

#include <pcap.h> #include <stdio.h> int main(void) { char errbuf[PCAP_ERRBUF_SIZE]; pcap_if_t *devs = NULL, *d; /* 枚举网卡，失败时 errbuf 里会有具体原因 */ if (pcap_findalldevs(&devs, errbuf) == -1) { fprintf(stderr, "findalldevs failed: %s\n", errbuf); return 1; } for (d = devs; d != NULL; d = d->next) { printf("%-12s %s\n", d->name, d->description ? d->description : "(no description)"); } pcap_freealldevs(devs); return 0; }

编译命令直接用pkg-config取参数，避免手写路径：

gcc sniff.c -o sniff $(pkg-config --cflags --libs libpcap) ./sniff

如果编译阶段报pcap.h: No such file or directory，是--cflags没生效；如果链接阶段报undefined reference to pcap_findalldevs，是--libs没生效或者静态库路径不对。两种情况都回到 5.2 检查pkg-config的输出。

运行阶段如果输出findalldevs failed: socket: Operation not permitted，那不是编译问题，是权限问题。枚举网卡在某些发行版上需要CAP_NET_RAW，用sudo ./sniff再跑一次就能区分。

5.4 链接结果反查

程序能跑之后，再做一步反查，确认它链接的确实是自己编的那份库，而不是系统里残留的旧版本：

# 静态链接时看编译产物里有没有符号 nm ./sniff | grep -c " T pcap_" # 动态链接时看运行时依赖 ldd ./sniff | grep pcap

静态链接的情况下ldd不会显示 libpcap，因为代码已经合进可执行文件了，这时候用nm数一下pcap_开头的符号数量，大于零就说明链进去了。动态链接的情况下ldd会打出libpcap.so.1 => /opt/offline-pcap/lib/libpcap.so.1，路径必须是/opt开头，如果显示/usr/lib就说明链接到了系统旧库，需要回头检查-L参数顺序。

6. 避坑清单：四个翻车现场和一个收尾习惯

离线编译这条链路上，失败几乎都集中在几个固定位置。下面四条是我在几台机器上反复遇到的，每条按现象、原因、解决写清楚。

现象一：gcc 的configure跑到一半退出，日志里写Building GCC requires GMP 4.2+, MPFR 2.4.0+ and MPC 0.8.0+。原因是download_prerequisites在离线环境里根本跑不通，三个数学库一个都没到位。解决是把 gmp、mpfr、mpc 的源码包提前放进src/，解开后用gmp、mpfr、mpc三个不带版本号的软链接对到 gcc 源码目录下，再重新configure。

现象二：编 libpcap 时报syntax error, unexpected ...，报错位置在自动生成的grammar.c里。原因是用了系统自带的 bison 2.7，生成的代码和新版语法文件不兼容。解决是command -v bison确认路径，必须是$PREFIX/bin/bison，不是的话在脚本里把PATH前置并加hash -r，然后make clean重新生成。

现象三：libpcap 编译通过，程序运行时却报error while loading shared libraries: libpcap.so.1: cannot open shared object file。原因是装到了/opt下，但ldconfig的搜索路径里没有这个目录。解决是往/etc/ld.so.conf.d/写一个 conf 文件把$PREFIX/lib和$PREFIX/lib64加进去，执行ldconfig，之后换用户、换 shell 都不受影响。

现象四：make -j16跑到一半，某个cc1进程突然消失，make 报一个和代码无关的错误。原因是并行度按核数给，内存被打爆，OOM Killer 直接杀进程。解决是按内存算并行度，取nproc的一半，内存特别小的机器再减半，宁可慢一点也不要中途崩。

脚本写到最后，我养成了一个习惯：每个包装完立刻把command -v和--version的第一行追加到一个manifest.txt里，全部跑完再统一看一遍。这个文件在出问题的时候就是唯一的黑匣子，能一眼看出是哪个包没切过去。从那以后我每次做离线编译，都强制先把 m4、bison、flex 的实际路径打出来贴进日志，再开始编 libpcap，后悔药这东西，提前备好总比事后找强。希望帮到你。

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