Wireshark mailing list archives

Re: Pointers needed for building Wireshark 2.6.3 on a Raspberry Pi model 3B (armv7 processor?)


From: Guy Harris <guy () alum mit edu>
Date: Wed, 12 Sep 2018 10:47:06 -0700

On Sep 10, 2018, at 9:46 PM, Geoff Lee <geoff.lee99 () gmail com> 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?
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

Current thread: