Wireshark · Wireshark-dev: Re: [Wireshark-dev] Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 p

[Guy Harris <guy@xxxxxxxxxxxx>]

On Sep 10, 2018, at 9:46 PM, Geoff Lee <geoff.lee99@xxxxxxxxx> wrote:
 
> My core problem is that I’m too new to Cmake to understand what *to do* about the messages I’m seeing in CMakeError.log

As João said, what you do with them is *ignore* them.

CMake does a number of tests to determine, for example, whether certain compiler flags are supported by the compiler you're using, and whether certain libraries are available on your system, and whether certain functions are available in various libraries.

Those tests may fail, in which case the failure will be reported in CMakeError.log.  The failure of a test doesn't necessarily mean that Wireshark can't be built; for the examples I have:

	if a compiler flag that makes the compiler issue warnings for certain possible code errors isn't supported by the compiler you're using, the build process just won't use that compiler flag - it means the compiler won't do as many checks of the code as other compilers do, but that's not a fatal problem;

	if a library that Wireshark doesn't require is missing, the build process just won't try to link with that library - it may mean that some Wireshark features aren't supported, but that's not a fatal problem;

	if a function that Wireshark doesn't require isn't available in the expected library, Wireshark will just be built not to call that function - it may mean that some Wireshark features aren't supported, but that's not a fatal problem.

One of the messages in your CMakeError.log file is:

	Performing C SOURCE FILE Test C__Wheader_guard_VALID failed with the following output:
	Change Dir: /home/Geoff/wireshark/wireshark-ninja/CMakeFiles/CMakeTmp

	Run Build Command:"/usr/bin/ninja" "cmTC_7c4c5"
	[1/2] Building C object CMakeFiles/cmTC_7c4c5.dir/src.c.o
	FAILED: CMakeFiles/cmTC_7c4c5.dir/src.c.o /usr/bin/cc    -fexcess-precision=fast -std=gnu99  -DC__Wheader_guard_VALID -fPIE   -fexcess-precision=fast -Wheader-guard -o CMakeFiles/cmTC_7c4c5.dir/src.c.o   -c /home/Geoff/wireshark/wireshark-ninja/CMakeFiles/CMakeTmp/src.c
	cc: error: unrecognized command line option '-Wheader-guard'
	ninja: build stopped: subcommand failed.

This just means that the -Wheader-guard flag, which is not available in GCC, and was first available in Clang 3.4:

	http://releases.llvm.org/3.4/tools/clang/docs/ReleaseNotes.html

which says that

	-Wheader-guard warns on mismatches between the #ifndef and #define lines in a header guard.

		#ifndef multiple
		#define multi
		#endif

	returns warning: ‘multiple’ is used as a header guard here, followed by #define of a different macro [-Wheader-guard]

"Header guards" are used in header files if including a header file more than once in a source file would cause errors or warnings (or even just a performance hit when compiling), for example a header "foo.h" might be:

	#ifndef FOO_H
	#define FOO_H

	typedef struct _foo {
		...
	} foo_t;
	extern void foo_init(void);
	extern foo_t *foo_create(const char *name);
	extern void foo_destroy(foo_t *foo);

		...

	#endif

so that if your program includes "foo.h" *and* includes a "bar.h" header that also includes "foo.h", only the first include of "foo.h" will define the "foo_t" data type and declare the functions that manipulate that data type.

If the #define doesn't use the same name as the #ifndef, that won't work, so it's a programming error error (although it's legal C, so it's not something all C compilers reject), and needs to be fixed.  However, that's mainly an issue for the developer, so the fact that your compiler won't perform that check isn't a problem; it just means that *your* compilation won't use that flag.

So that's *not* an error about which you need to do anything.

The main purpose of CMakeError.log is to help *developers* debug tests they've put into the CMake files.  An end user trying to compile some code doesn't need to look at the file; they'd just need to send it to the developers of the code in case CMake doesn't succeed in configuring for some non-obvious reason, or if it does but the build fails for some mysterious reason, so the developers can figure out what the problem is and how to fix it.

> and CMakeOutput.log

At leas some of the *warnings* there are just indications that the test programs being compiled by CMake to perform its tests aren't *so* carefully written as to avoid compiler warnings that don't affect the validity of the test:

Performing C SOURCE FILE Test HAVE_NL80211_SPLIT_WIPHY_DUMP succeeded with the following output:
Change Dir: /home/Geoff/wireshark/wireshark-ninja/CMakeFiles/CMakeTmp

	Run Build Command:"/usr/bin/ninja" "cmTC_4e801"
	[1/2] Building C object CMakeFiles/cmTC_4e801.dir/src.c.o
	/home/Geoff/wireshark/wireshark-ninja/CMakeFiles/CMakeTmp/src.c: In function ‘main’:
	/home/Geoff/wireshark/wireshark-ninja/CMakeFiles/CMakeTmp/src.c:3:35: warning: unused variable ‘x’ [-Wunused-variable]
	    enum nl80211_protocol_features x = NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP;
                                   ^
	[2/2] Linking C executable cmTC_4e801

	Source file was:
	#include <linux/nl80211.h>
			int main(void) {
				enum nl80211_protocol_features x = NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP;
			}

This is just testing whether a particular Linux-specific option is available; all it needs to do is check whether linux/nl80211.h defines NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP.  There's no need to have the test program include code to *use* the variable "x" - all it needs to do is try to set the variable to the value of that option, which will fail if it's not defined and succeed if it is defined; it's just that, as Wireshark builds with a lot of warning flags (to catch various errors that really should be corrected:

	https://blogs.msdn.microsoft.com/vcblog/2017/12/13/broken-warnings-theory/

and CMake uses the Wireshark compiler flags when building programs in its tests, some warnings happen to be produced if it's not used.  All CMake is doing is checking to see whether a "NL80211_PROTOCOL_FEATURE_SPLIT_WIPHY_DUMP isn't defined" error is generated, so it's just checking for errors, not warnings.

So CMakeOutput.log, like CMakeError.log, is just a file for developers (or users who want to act as developers and fix problems when they try to build).  Ignore errors.

> I’m hoping that my problem is basic enough that with a few pointers about what to look at or learn about next, it can be solved.

I'm not yet sure you *have* a problem!

If CMake's output (standard output and standard error), when you ran it, said something such as

	CMake Error ...:
	  {message}


	-- Configuring incomplete, errors occurred!

then you do have a problem, and can't do the build.  The {message} is what's important; yes, the message also says

	See also "{your build directory}/CMakeFiles/CMakeOutput.log".

	See also "{your build directory}/CMakeFiles/CMakeError.log". 

but you don't need to see them unless 1) the {message} seems to indicate that something is wrong that shouldn't be wrong (for example, claiming that it couldn't find libpcap when the system has libpcap - including the developer's package, if necessary - installed) and 2) you're sufficiently familiar with the tests CMake is doing that you can try to fix that problem yourself.

So did you get a "Cmake Error" message and, if so, what was the message on the next line?