I'm debugging a very large project and I added in one file: "file_1.c" an include statement for another file #include "header_2.h". I got 2 compilation errors:
error (dcc:1633): parse error near '100' (Built from Project 'project_3')
error (dcc:1100): member is incomplete (Built from Project 'project_3')
but the locations of the errors didn't make sense, because the code there was part of a typedef:
typedef struct
{
unsigned char A:1, // <- first error here (dcc:1633)
B:1,
C:6;
}TYPE_A;
typedef struct
{
TYPE_A D; // <- second error here (dcc:1100)
TYPE_B E;
TYPE_C F;
}FOO_T;
Now, this header header_2.h is included in other c files and gave me no problems.
I thought that the case here could be circular include but I checked the header and there are include guards there. Once I remove the include, the parse errors disappeared and the compilation run OK (since the include was planted there for some code piece I removed).
I also checked the actual include line (in file_1.c) to see if maybe there was a parse error there, but nope.
What can cause this problem and how should I handle it?
Note: the header itself is error free. It is included in other c files and shows no errors there. Also, without this specific include, the compiler runs fine.
Probably the header which causes the problem contains something like
#define A 100
which changes the meaning of the token A.
That will only cause issues if the macro defined in the header is inadvertently used in another file; by themselves, the header and the other file are unproblematic.
Related
I'm trying to compile libpcap with cross compilator arm-linux-gcc. When I run 'make' I get an error:
./pcap-linux.c:254:14: conflicting types for socklen_t /usr/arm-linux-gnueabi/include/unistd.h:275:21: note previous declaration of 'socklen_t'
I've also tried to compile it using common gcc but i have the same error. I work on ubuntu. How to resolve this problem
pcap-linux.c makes an alias in next way:
#ifndef HAVE_SOCKLEN_T
typedef int socklen_t;
#endif
You should pass -DHAVE_SOCKLEN_T to compiler or put
#define HAVE_SOCKLEN_T
to some header (usually it is done automatically by configure script or similar, that generates config.h).
Seems like you skipped build configuration step, so be ready to see another weird build errors.
./theheader.h:349: Error: Syntax error in input(3).
Offending line:
string read_gdbm(GDBM_FILE dbf, string key_str, bool show_err = gbls.verbose);
Any ideas?
Typically, a syntax error in SWIG means that it can't understand the line in question (which can be annoying, because the line numbers don't follow macros such as %defines). So I suggest you check that string (should it be std::string? has it been defined?), GDBM_FILE (has it been defined? should it be in a namespace?) and maybe gbls.verbose (has it been defined?) make sense to SWIG. It may help to run swig with the -E option (be sure to redirect the stdout), find the corresponding line and search backward for each type involved. You may need to add some #includes.
Also check the previous line, to ensure you're not missing a semicolon, or something like that.
As a side note, I've run into the same issue for different reasons: I was trying to use a vector < vector < double >>. Now the ">>" character sequence mustn't be used with templates according to the C++99 standard, hence the swig error message popped up. The solution was to simply add an extra space to separate them.
I hit a similar error. I'll clarify my process, hope it can be helpful.
lib.i:
...
%begin %{
#include "header1.h"
%}
...
%include "header1.h"
header1.h:
19 typedef struct T {
...
23 } PACKED TlvHdr;
The error message just as below
./header1.h:23: Error: Syntax error in input(3).
I check the SWIG doc(http://www.swig.org/Doc1.3/SWIG.html 5.7.1) and found that the syntax error is so common, it's probably caused by a SWIG bug.
The doc recommended when encountering a syntax error to use #ifndef SWIG to omit statements that will make SWIG parser issue an error. So I changed the header1.h file, then the error disappeared.
header1.h:
#ifndef SWIG
19 typedef struct T {
...
23 } PACKED TlvHdr;
#endif
If you can't modify theheader.h file, you can make a new header file that just contains the declarations you need and replace the file from theheader.h to your new header file at %include directive
I had a similar issue and -E helped me understand that a macro definition was hidden inside an #ifndef SWIG block. I suspect that here it does not see the definition of GDBM_FILE, likely because it does not recurse.
I was trying to compile a 3-file C programme with 1 file cointaining tha main() , one containing headers related to a struct type I created and the third one the functions related to the struct. I was getting an error on the return temp; on a function in the third file, and I finally realized that I should remove the header in that file in order the functions the work properly, but I have no idea why that worked!!
Could someone please explain me why?
Check:
You put header guards in your header files
You don't have function or object definitions in your headers but only declarations.
I'm not totally sure but this looks wrong:
I have a header file named fraction.h in which I store a fraction structure and the methods to handle it, one method is used to write a fraction in a file and in the signature of this function one argument is a FILE pointer.
fraction.h:
...
const Fraction * fraction_fwrite(const Fraction * f, FILE * file);
...
fraction.c:
#include <stdio.h>
#include "fraction.h"
...
Now when I try to compile a program that uses a fraction, I get an error,
here is what I have in my Makefile:
program_test: fraction.o program_test.o
and I include fraction.h in program_test.c of course.
but I keep getting this error :
fraction.h:34:54: error: unknown type name 'FILE'
someone could explain the different steps through which the compiler includes files ?
because <stdio.h> is in fraction.c so why does it strike this unfound-type error ?
should I include <stdio.h> in fraction.h ? which looks not really appropriate from my measly experience.
When you compile program_test, the compiler isn't looking at the other .c files, only the files you #include in the file you actually compile.
So, you either have to #include <stdio.h> in the test program, just like in fraction.c, or include it in the header file.
Even though the C standard says that the standard library files will not include each other, there is nothing saying that user defined files cannot do that. In fact it is usually much easier to use them if they do.
When the preprocessor processes a file, then it will copy the content of an included file into the file that is preprocessed. The reason why you don't get that error in fraction.c is that the content of stdio.h is included before fraction.h is included.
So the preprocessed file fragments.c looks like this:
stdio.h contents
fragment.h contents
fragment.c contents
Notice that the FILE definition will be included through stdio.h before it is referenced in fragment.h.
You should include stdio.h in fraction.h to get rid of this error.
Include stdio.h in program_test.c. If you dont include stdio.h in program_test.c (which includes fraction.h), the compiler doesn't know the definition of FILE used by fraction.h, and generates error.
And, you really should include stdio.h in fraction.h
I have a header file (sample.h) for my c file (sample.c). When I prototyped a function in my header file as below.
return_type sample_fun (FILE *filePtr);
I get a compilation error saying, Syntax error: possible missing ')' or ','? When I include the stdio.h error is resolved. Is the stdio.h include mandatory? Some of my files work well without the include.
I use gcc on AIX.
Yes, the type FILE is defined in stdio.h; if you mention it, then you must include that file.
Yes it is. FILE is typedefed from a struct iobuf on most platforms. This requires that the full definition of struct iobuf be present, even though all the interfaces use FILE *, and pointer types do not normally require full definitions prior to their use (C limitation).
See this question for more information: Forward declare FILE *