fix(fuzz): build a minimal libpcap for oss-fuzz targets instead of linking the system one (#1092)

[fklassen]

Fixing this ahead of a resubmission to OSS-Fuzz - found by the actual OSS-Fuzz build matrix (google/oss-fuzz#15924), not locally.

The failure

Every target across every engine/sanitizer combination OSS-Fuzz tried failed at startup:

error while loading shared libraries: libpcap.so.0.8: cannot open shared object file: No such file or directory

The build itself succeeded. OSS-Fuzz's separate builder and runner images are the reason: the builder has libpcap.so because that's what apt-get install libpcap-dev put there, but the runner - where the built binaries actually execute during check_build/fuzzing - installs libcap2 only (per upstream infra/base-images/base-runner/install_deps.sh), not libpcap. A build that reports success but produces nothing that can run is worse than one that fails outright.

Why simply linking libpcap statically doesn't work

I tried that first. It doesn't fix anything - it just moves the missing library. Debian/Ubuntu's libpcap is built with D-Bus, Bluetooth, and USB-sniffing support enabled, so the static archive pulls in libdbus-1 and libsystemd (which itself needs libcap's cap_* symbols). Verified locally by trying exactly that and watching the missing-shared-library error move from libpcap.so to libdbus-1.so to a cap_get_proc link failure, one hop at a time.

The actual fix

None of that capture-backend code (D-Bus, Bluetooth, USB) is reachable from reading a pcap file, which is all these targets ever do. build.sh now clones and builds its own libpcap from source with -DDISABLE_DBUS=ON -DDISABLE_BLUETOOTH=ON -DDISABLE_LINUX_USBMON=ON -DDISABLE_RDMA=ON - matching what the actual libpcap OSS-Fuzz project's own build.sh already does, for this same reason. The result depends on nothing beyond libc/libstdc++/libm.

libpcap-dev stays in the Dockerfile for tcpreplay's own normal build (which still links the system package, unchanged) - only the fuzz targets' link step now uses the self-built copy.

Verification

Built a fake $SRC locally with both a fresh tcpreplay checkout and a fresh libpcap clone - exactly what the Dockerfile produces - and ran the actual updated build.sh against it with $CC=clang/$CXX=clang++/ASan+UBSan+libFuzzer flags:

• All three targets built.
• ldd on each shows only libstdc++/libm/libresolv/libgcc_s/libc/ld-linux - no libpcap.so, libdbus-1, or libsystemd.
• Each passes OSS-Fuzz's own bad_build_check invocation exactly: -rss_limit_mb=2560 -timeout=25 -seed=1337 -runs=4 < /dev/null → exit 0. That's the precise check that was failing in the real CI run.
• Each still runs cleanly against the checked-in corpus.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NBmWiWg46r8BLbdwozKo6v