Hello, I am trying to build wireshark for Windows 7. During the build process, CMake finds the modules GMODULE2 and GTHREAD2 in the wrong locations which then causes build/linker errors in the msbuild step. For GMODULE2, CMake finds the following:
However, it should be looking under:
The same issue occurs for GTHREAD2, but does not occur for other modules such as GLIB2 and GNUTILS. Could this have something to do with pkg-config and Cflags in the downloaded Wireshark-win64-libs-2.2/lib/pkgconfig directory? I noticed that there are no Cflags for gmodule-2.0.pc and gthread-2.0.pc, while there are Cflags for other modules such as glib-2.0.pc. I'm also open to suggestions as to other possible causes of this problem. Thank you asked 21 Feb '17, 13:39  plinli |
One Answer:
What version of Wireshark? The Windows CMake build doesn't make use of the pkg-config files. Wireshark provides a CMake module These "hints" are then added to the search path for a particular library, and then the CMake Common issues in this area occur because Cygwin or Git user commands have been added to the path. Can you determine if you do have something on your path that would lead to these erroneous libs and includes? answered 22 Feb '17, 05:56  grahamb ♦ Removing Cygwin from %PATH% fixed the problem. Thank you. (24 Feb '17, 07:59) plinli 1 @plinli I've moved things around so we have a clear answer. If an answer has solved your issue, please accept the answer for the benefit of other users by clicking the checkmark icon next to the answer. Please read the FAQ for more information. (24 Feb '17, 08:15) grahamb ♦ |
I am working with Wireshark 2.2.4. Windows 32 and 64 bits.
Before running CMake, I set the
WIRESHARK_BASE_DIRenvironment variable to my Wireshark base directory.I found that
GMODULE2_HINTSis set to the correct module path, but thatGMODULE2_INCLUDE_DIRSandGMODULE2_LIBRARIESalready have the erroneous libs and includes values prior to calling thefind_path()andfind_library()functions, respectively. The same occurs for GTHREAD2.To clarify, by "Common issues in this area occur because Cygwin or Git user commands have been added to the path", do you mean the Windows environment variable %PATH% or are you referring to an internal CMake variable?
Also, is there an alternative solution that does not require changing the path?
Thank you.
The Windows PATH, but now I think on it I can't actually recall that causing issues with finding libraries and headers, mostly executables.
I do think it's something in your environment though. I debug these issues by placing CMake
message(SEND_ERROR "CMake var xxx is $cmake_var_xxx")into the modules and CMakeLists.txt files.Are you sure that you've either removed the offending lines from, or deleted the file entirely, CMakeCache.txt in the build dir before rerunning CMake? CMake won't look anew for things it's already found.
Also, don't forget that you can always check the buildbot
stdiologs and compare the buildbot's environment, etc. with your own. There are logs for each step by each buidbot, so look at those that are relevant to you. See: https://buildbot.wireshark.org/wireshark-master/waterfallMy Windows %PATH% variable does include Cygwin (specifically,
c:\cygwin\bin)Even if I remove the build directory including the CMakeCache.txt within it, the errors still occur.
However, if I call
unset(<VAR> CACHE)on theGMODULE2_FOUND,GMODULE2_INCLUDE_DIRSandGMODULE2_LIBRARIESvariables, then CMake is able to find the correct paths using thefind_path()andfind_library()functions.I've compared the CMakeCache.txt of the successful and unsuccessful builds and found the following:
GMODULE2_INCLUDE_DIRS:PATHandGMODULE2_LIBRARIES:FILEPATHare defined in the successful build, but do not exists in the erroneous one.GMODULE2_FOUND:INTERNAL,GMODULE2_INCLUDE_DIRS:INTERNALandGMODULE2_LIBRARIES:INTERNALare defined and set to the incorrect values in the failed build and do not exist in the successful one.Do you have any ideas as to why this might occur? and why the env vars might be initialized to the wrong values?
Thanks.
I guess you should verify that if the Cygwin bin directory is NOT on the path whether the CMake behaviour changes.