Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Cannot find krb5.h

From: Graham Bloice <graham.bloice@xxxxxxxxxxxxx>
Date: Thu, 7 Feb 2019 12:59:44 +0000


On Thu, 7 Feb 2019 at 12:45, Pascal Quantin <pascal@xxxxxxxxxxxxx> wrote:
Hi David,

Le jeu. 7 févr. 2019 à 12:58, <david_aggeler@xxxxxxxxxx> a écrit :

 

I’ve updated my machine to VS2017, Latest, Qt, Git, Python, …. And I got rid of cygwin and vs2015

The setup should match the instruction, but apparently not quite. (win10, x64)

 

Right now I fail to build latest master (a clean build does not help, deleting all libs neither)

 

"C:\Development\current\wsbuild64\epan\dissectors\dissectors.vcxproj" (default target) (101) ->

       (ClCompile target) ->

         ./asn1/kerberos/packet-kerberos-template.c(260): fatal error C1083: Cannot open include file: 'krb5.h': No such file or directory (compiling source file C:\Development\current\wireshark\epan\dissectors

       \packet-kerberos.c) [C:\Development\current\wsbuild64\epan\dissectors\dissectors.vcxproj]

 

The prep downloaded and extracted ‘krb5-1.17-win64ws’.

 

Any ideas on which component, environment variable, setting … am I missing?


So what's the content of the CMakeCache.txt file in your build folder? Mine contains the following lines and I have no issue building Wireshark source code:

//Kerberos DLL list
KERBEROS_DLLS:FILEPATH=comerr64.dll;k5sprt64.dll;krb5_64.dll

//Path to the Kerberos DLLs
KERBEROS_DLL_DIR:PATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/bin

//Path to a file.
KERBEROS_INCLUDE_DIR:PATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/include

//Path to a library.
KERBEROS_LIBRARY:FILEPATH=C:/Wireshark-win64-libs/krb5-1.17-win64ws/installed/x64-windows/lib/krb5_64.lib

Best regards,
Pascal.


This is a bit of an annoyance when a package is updated that has a new path in the libs directory, in that you have to either delete CMakeCache.txt entirely and regenerate it (slow), or edit it to remove the old paths, not much quicker and error prone.

I've been thinking about this for a while, what I think we could do is invalidate the CMake cache variables when a lib is updated.  How we wire all that up is the more difficult part.  There is the get_cmake_property(_var VARIABLES) command that will list all variables (it does say this is for debugging though), we could make a guess that all vars for a lib start with the lib name, iterate over the list and if a suspect is found unset() it.  The list of libs to unset would have to be passed back from the PowerShell script.

--
Graham Bloice