On Sep 10, 2018, at 9:46 PM, Geoff Lee <geoff.le...@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-requ...@wireshark.org?subject=unsubscribe
