Wireshark-dev: Re: [Wireshark-dev] Reply ASAP: Compilation error

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Sun, 23 Oct 2011 12:13:29 -0700
On Oct 23, 2011, at 12:31 AM, Krishnamurthy Mayya wrote:

> packet-mpls.c: In function ‘dissect_pw_ach’:
> packet-mpls.c:389: error: implicit declaration of function ‘printf’
> packet-mpls.c:389: error: incompatible implicit declaration of built-in function ‘printf’

If you are using printf() (which I hope you're only using for debugging purposes, as dissectors shouldn't print stuff to the standard output or error - the user might never see it), you must include <stdio.h>.

> packet-mpls.c: In function ‘dissect_pw_ach_mplstp’:
> packet-mpls.c:1069: error: implicit declaration of function ‘dissect_bfd_control’

The only dissect_bfd_control() in the Wireshark source is in epan/dissectors/packet-bfd.c, and it's static.  If your changes to the MPLS dissector require that dissect_bfd_control() to be called, you will need to:

	make it *not* static;

	create an epan/dissectors/packet-bfd.h file that includes a declaration of dissect_bfd_control();

	include that file in both epan/dissectors/packet-bfd.c and epan/dissectors/packet-mpls.c.

> packet-mpls.c:1096: error: implicit declaration of function ‘dissect_mpls_echo’

That's presumably a function you've written.  If it's not used outside epan/dissectors/packet-mpls.c, make it static and, if it's called before it's defined, put a forward declaration of it before the first call.

> Any idea about what might have gone wrong??

You failed to arrange that functions be declared before they were called.

> The most confusing fact is another line that appears above these error codes: cc1: warnings being treated as errors

That means, as Richard van der Hoff indicated, that our build procedure configures the compiler to, if possible, treat warnings as errors and to cause the compile to fail, so that the errors have to be fixed.  Most warnings are, in fact, errors in that they represent incorrect code, even if they happen to be valid C code in the sense that they don't violate the C language specification.

> So we dont know whether these are really errors or warnings treated as errors.

You should not care whether really errors or warnings treated as errors; you should fix them in either case.

> If errors, all kinds of suggestions are welcome.

See above.