Guy Harris

> Any way to build without the capture function ? "Build" as in "build libpcap" or "build" as in "build tcpdump"? Libpcap *can* be built without capture support - if...

> This way, there is indeed some amount of resources not explicitly freed before the exit. The `pcap_t` is also not closed. In some situations closing a `pcap_t` performs some...

the-tcpdump-group/libpcap#1237 appears to work around this problem in libpcap; I'll propagate that change to tcpdump and tcpslice. We should still figure out what version of CMake we should require on...

> We should still figure out what version of CMake we should require on UN*Xes. Repology is your friend - https://repology.org/project/cmake/versions. CentOS 6 and 7 still offer CMake 2.8.12.2, so...

So is this because, even if a program uses another library, already configured with large file support, to do some of its file reading and writing, the program *itself* must...

This won't fix the problem for people using CMake; see cmake/Modules/FindLFS.cmake, and the "Large file support on UN*X, a/k/a LFS." section of CMakeLists.txt, in the libpcap source for the sort...

> Right, it's not infectious (unless libpcap stores it in one of its installed headers, and AFAICT it doesn't) If it did store stuff therer, it would presumably have infected...

> unless there are `stat()` calls in tcpdump that would need to be made to call `_fstati64()` rather than `_fstat()`, We already handle those similarly to how libpcap handles them...

And the fix won't mess up tcpdump with one of those no-large-file-support libpcaps, as you won't get a file offset > 2^31-1, even though the call will return a 64-bit...

> Can you see if https://github.com/the-tcpdump-group/tcpdump/pull/1012/files addresses the Snmp ub you see? It does, at least on my Ubuntu 22.04 VM. Tested by reverting to a version of print-snmp.c prior...