Guy Harris

It does not happen when building libpcap by itself with CMake, using the Ninja generator and the Ninja build tool. Perhaps there's something in the way you're including it. What...

This is *not* a problem when trying to build libpcap. It's a problem when trying to build *other* software that has `#include ` and that, for some reason, heppens to...

> https://github.com/nmap/nmap/issues/2747 Nmap, for some unknown reason, has its own version of libpcap in its source code, and searches in the libpcap source directory for headers. That should be cleaned...

> https://groups.google.com/g/tesseract-ocr/c/MpCZe5wRYQE For some unknown reason, the build process is looking for header files in the top-level source directory. They need to fix it not to do so.

In what fashion does your project use libpcap? If it just *compiles and links* with libpcap, there's no reason to include the entire libpcap project source into your own project...

As that issue says: > The complication seems to be caused by providing the full libpcap source tree to a 3rd-party build process. [I suggested restructuring the source directory for...

> In less common use cases that genuinely demand a full copy of libpcap source (with or without modifications) the expectation is that the project developers know very well what...

> It seems to me that #include (no .h) is the part that's broken. The ".h" in header file names is a convention, rather than an absolute requirement. In C...

> The first one is calling 'pcap_findalldevs_ex' causing "A Winsock API was called before a successful WSAStartup() or after a balancing successful WSACleanup() call was made". Does their sample code...

This whole `WSAStartup()`/`WSACleanup()` thing sounds like an ugly leftover from the Win16 days; UN\*Xes never had that mess. `WSAStartup()` and `WSACleanup()` maintain a counter, so that `WSAStartup()` doesn't do any...