I have a project written in C consisting of FIFO.h, FIFO.c, task.h, task.c and main.c (it's a basic queue).
When I compile my main.c using gcc under Windows it compiles and works just fine. However when I try to compile the exact same code in Eclipse, I get the following error for every function:
One example is:
In function `queue_new':
FIFO\Debug/../src/QueueFIFO.c:20: multiple definition of `queue_new'
src\main.o:FIFO\Debug/../src/QueueFIFO.c:20: first defined here
src\FIFO.o:
I honestly have no idea what additional information you guys could use so just tell me what to do.
main.c includes:
#include "FIFO.h"
#include "FIFO.c"
#include "task.h"
QueueFIFO.c:
#include "task.h"
FIFO.c:
#include "task.h"
#include "QueueFIFO.c"
task.c:
#include "task.h"
You are getting multiple definition errors because you are including your .c files in your .c files. It's the linker's job to make sure they come together. Good practice is to only include .h files in your .c files, and make sure the .h files don't include function definitions (only function prototypes).
By #includeing your .c files, you are defining the functions at least twice: once when FIFO.c is compiled, and again when main.c (which #includes FIFO.c, copying it verbatim into the text before compilation) is compiled. When it comes to link time, the linker sees e.g. queue_new() defined in both FIFO.o and main.o and barfs on the multiple definition of all the functions in FIFO.c.
In addition, as others mentioned, make sure you "guard" your header files to make sure they don't create circular #include dependencies. You can do that with #ifndef and #define as follows:
/* foo.h */
#ifndef FOO_H
#define FOO_H
#include "bar.h"
#include "baz.h"
/* header file contents go here */
#endif /* FOO_H */
This has the effect of only executing the contents of the file once, since FOO_H will be defined if it is included a second time, and the entirety of the file will be skipped over.
Related
I am writing a rather large program in C and I had a question about header files. My main file includes my library header containing all of the function declarations. In the files that contain my function definitions, I have them include that same header file. When I compile, I link all the object files together.
It occurred to me that instead of having my definition files include the header file and then linking the results together, I could simply have the header file include the definitions at the END of the header file, like:
#ifndef HEADER
#def HEADER
#include <stdio.h>
#include <hdf.h>
... (function declarations)
#include "definition1.c"
#include "definition2.c"
#endif
What would be the benefits of doing it this way versus what I have now?
I have a C program named coderTest.c in a directory. In a sub-directory, src, I have several files, one.c, two.c, three.c, and their associated header files one.h, two.h, three.h.
I want to use functions from one.c and two.c in coderTest.c. Both one.c and two.c use functions from three.c. Do I need to include three.c in coderTest.c, or will it take care of it's dependency on it's own?
I am using #include "src/one.h" for one and two.
Do I need to include three.c in coderTest.c, or will it take care of
it's dependency on it's own?
You don't need to include "src/three.h" in coderTest.c, but this does not mean, that compiler does handle dependency automagically. This header needs to be included in one.c, two.c and three.c. The last one is to confirm that header's declarations and definitions match with each other properly.
As a result, you project might look as:
coderTest.c:
#include "src/one.h"
#include "src/two.h"
// ...
src/one.c:
#include "one.h"
#include "three.h"
// ...
src/two.c:
#include "two.h"
#include "three.h"
// ...
src/three.c:
#include "three.h"
// ...
To prevent multiple includes of same header, use header guards for each header file individually.
In coderTest.c, include the following:
#include "src/two.h
#include "src/one.h
In one.c, include:
#include "src/three.h
In two.c, include:
#include "src/three.h
Do I need to include three.c in coderTest.c, or will it take care of it's dependency on it's own?
No you don't need to include three.c in coderTest.c, because one.c and two.c abstract it away.
As long as two.c and one.c properly #include "three.h" then the compiler will be able to chain the dependencies together without a problem. If you wanted to run something from three.c in coderTest.c it would want you to #include it in there as well.
Do your files have the preprocessor directives #IFNDEF, #DEFINE, and #ENDIFin place to prevent duplicate importing?
You can do what you want several ways as long as visibility to necessary prototypes is provided. In addition to where best to include header files, consider using wrappers to guarantee your header is used only once:
#ifndef _SOMEFILE_H_
#define _SOMEFILE_H_
the entire file
#endif /* SOMEFILE_H__SEEN */
Also consider readability. For example given: coderTest.c, one.c/.h, two.c/.h, three.c/.h are as you described:
1) You should include three.h in both one.c and two.c.
2) For coderTest.c, #include headers of all supporting headers either in the file itself, or perhaps in a collector header: conderTest.h:
coderTest.h:
#include "./src/one.h"
#include "./src/two.h"
#include "./src/three.h"
coderTest.c
#include "coderTest.h"
I have a single main .c file with 4 .h files and .c files included into the main function. Like this:
#include <stdio.h>
#include "file1.h"
#include "file2.h"
#include "file3.h"
#include "file4.h"
int main(){...}
The .h files have all the declarations for all of their corresponding .c files. Some of the .c files do use functions from other .c files, for example "file4.c" uses some functions declared in "file2.h" and "file1.c" uses functions declared in "file3.h". I've tried declaring the same includes as in main in every .c file and tried reordering the include files, but I still get warning messages about implicit declarations of functions and incompatible implicit declarations.
I was wondering how you would use #includes in your large projects to eliminate warning messages. I'm using gcc as the compiler.
If you want import the .h file in a part of main() file, you must sure that you didn't import it anywhere.
For example:
file4.h use functions in file3.h
If you imported file3.h in file file4.h you have to not import file3.h in file main(). It's the duplicated definition.
If you have a lot of init files. You can import it in the only general file. And use that file in main().
Hope you like it ^^
Try this on all your own head files:
(beginning of your head file)
#ifndef _HEAD_FILE_NAME_H
#define _HEAD_FILE_NAME_H
...
<your headfile contents>
...
#endif
(end of your headfile)
Going through the RPC tutorial at MSDN,
I have just created a project with two .c files as following::
/* file hellop.c */
#include <stdio.h>
#include <windows.h>
void HelloProc(char * pszString)
{
printf("%s\n", pszString);
return ;
}
and
/* file: hello.c */
#include "hellop.c"
void main(void)
{
char * pszString = "Hello, World";
HelloProc(pszString);
return ;
}
Problem:: Error LNK2005 and fatal Error LNK1169
Why and where is the compiler seeing the multiple symbol definition or declaration of HelloProc(char*) ?
EDIT:: As concluded in this SO_Question, including .h file is the best solution obviously. But does that leave us with no implementation of design where we can include a .c file into another .c file?
Weird Behavior:: First time compilation runs fine but rebuild of solution breaks with the above mentioned errors. You can check the multiple first time compilation by changing the file name from .c to .cpp and vice-versa. Why does it exhibit this behavior? (I am not sure if anybody else have also experienced this with the given example)
You compiling HelloProc twice, as you include the whole definition of of this function in hello.c file by #include "hellop.c", while you only need declaration of it. You should put function prototype in header file.
#ifndef HELLOP_H
#define HELLOP_H
#include <stdio.h>
#include <windows.h>
void HelloProc(char * pszString);
#endif
And include header file both in hellop.c and in hello.c
Edit: #include is not cut-paste as you said, it is more copy-paste
# include "q-char-sequence" new-line
causes the replacement of that directive by the entire contents of the
source file identified by the specified sequence between the "
delimiters
so you get to linkage with two definitions of HelloProc one in hellop.c and another one in hello.c. Another way to solve it is to compile only hello.c file, this way there is no duplicate of HelloProc. See how to do it in VisualStudio here
I found these libraries: http://svn.opendnssec.org/trunk/OpenDNSSEC/common/ for encoding in c. I want used them but I am not sure how can I add them.
If I add #include "b64_ntop.c" I have problem with #include <config.h> in b64_ntop.c (no such file or directory). How can I add these modules?
My makefile:
CC=gcc
CFLAGS=-std=gnu99 -Wall -pedantic
all: rdtclient
rdtclient: b64_ntop.o rdtclient.o
$(CC) $(CFLAGS) b64_ntop.o rdtclient.o -o rdtclient
Thanks for help
For that particular file, you can remove every header except <stdlib.h> (needed for abort()), but you would add <stdint.h> to get uint8_t.
#include <config.h> // Remove
#include <sys/types.h> // Remove
#include <sys/param.h> // Remove
#include <sys/socket.h> // Remove
#include <netinet/in.h> // Remove
#include <arpa/inet.h> // Remove
#include <ctype.h> // Remove
#include <stdio.h> // Remove
#include <stdlib.h> // Keep
#include <string.h> // Remove
#include <stdint.h> // Add
There's no need for the others that I can see, and GCC agrees with me when I tested it.
I'm not sure which header introduced uint8_t; most likely, it was <sys/types.h>, but the C standard says <stdint.h> does that (or <inttypes.h> does it).
You should also have a header which declares the function, and that header should be included in this file to ensure that the function declaration and definition agree, and the header should be included in each source file that uses the function. Obviously, that's one more #include line in the source file.
In general, if a file uses <config.h> (or, more usually, "config.h"), then you need to use the configuration tool (usually autoconf or automake) or the configure script that is generated by the tools to create the config.h header. In this file, there was no conditional code affected by the configuration header, so it could be removed.
Once you've cleaned up the header list, you can treat the file as you would any other source file in your project. It would be best to compile it as a separate object file (no special options needed) which is added to the build. That's what your makefile seems to be doing perfectly well. Occasionally, it is sensible or necessary to include a source file (as opposed to header file) in another source file. The number of times that is sensible is strictly limited, though.
You should not #include a C file. Instead #include compat.h and specify the path to the header file in the CFLAGS using the -I option thus:
CFLAGS=-std=gnu99 -Wall -pedantic -Ipath/to/header