On Jan 4, 2019, at 2:38 PM, hdv <henri.de.veer@xxxxxxxxx> wrote:
> I'm not a guru on CMake, so no idea if the libraries are binary loaded (probably) or built locally. I even don't know in which lib it was before, it just worked and now this surprises me. I followed the installation instructions (more or less) for windows mentioned in the documentation.
For Windows builds, it was *never* in glibc. GNU libc is the C library for most Linux distributions, but it's rarely the C library on any other operating system, such as *BSD/macOS, Solaris, HP-UX, AIX, or Windows.
> No idea what is linked in windows exactly, it was working in the old commit and after rebase to one of the latest commits it does not link any more. So I would say it is a regression issue?
If your old CMake files were incorrect but happened to work before the change, but didn't work after the change, it's not a regression issue, but if they were correct, that's a regression issue, and *our* extcap programs are the ones that are getting linked with the Winsock libraries, on Windows, by luck.
Are you building your program in the extcap directory of the Wireshark source tree? If so, have you added it to the CMakeLists.txt file in that directory? If so, are you linking it with the wsutil library? That library is linked with the Winsock2 library on Windows, which is probably how the extcap programs get linked with Winsock2.
We need to do a better job of documenting in the Developer's Guide how to *build* an extcap program - we say how to *write* it, but I don't see anything about *building* it.
> Something is ripped out of a library (in the wireshark codebase),
getaddrinfo() is not in a library in the Wireshark code base, it's in a system library, so we didn't remove it from any library, and it was not removed from any system library on any system I know of.
What happened was that, before the change, your program was getting linked, on Windows, with the Ws2_32 library, but, after the change, it was no longer getting linked with that library.