I am doing a porting project implemented from INTEGRITY OS to UBUNTU. Facing compiler error as explained below. Even though not compiled in INTEGRITY OS, i think there is no errors there.
I got the root cause. I am expecting solution how i can achieve this.
main.c
#include "file1.h"
#include "file2.h"
#include "file3.h"
.
.
.
Inside all the files from
file1.h to file3.h below is there at the beginning of each file.
#ifdef INC_HEADER_FILE
#error Multiple header files included.
#endif
#define INC_HEADER_FILE
.
.
.
Above throws error while compiling
In file included from ../main.c:
../file1.h: error: #error Multiple application header files included.
# error Multiple application header files included.
^~~~~
Same error is thrown for all the files for file1.h to file3.h
If all three (or however many there are) of those header files use the same symbol INC_HEADER_FILE, then you will only be allowed to include one of them.
That's because including (for example) file1.h will set that symbol, meaning that including the next header will complain because it's already defined.
The include guard symbol is usually specific to the header file itself, such as INC_HEADER_1_FILE but it's my no means necessary - I've seen this sort of thing done when you only want one variation of a header file.
An example of that is a system I worked on for LED display devices where each header had different dimensions. These were constructed from 8x8 units but different quantities across and down. Having the LED addressing map in a header file allowed for efficiencies that weren't available with dynamic configuration and the include guard made sure we didn't try to use more than one map.
regarding the include guard for header1.h suggest:
#ifndef HEADER1_H
#define HEADER1_H
...
#endif
regarding the include guard for header2.h suggest:
#ifndef HEADER2_H
#define HEADER2_H
....
#endif
and similar for each header file.
The result is in any one compilation unit (source file.c) any specific header file can only be included once.
Related
I'm creating a new project in keil to learn how to add files and headers and link them properly. I need some help in understanding the optimised way to add header files.
I've a main.h file, in that I've included FU68xx.h, adc.h and gpio.h file.
#ifndef HEADER_FILE
#define HEADER_FILE
#include <FU68xx.h>
#include "adc.h"
#include "gpio.h"
#endif
In "adc.c" and "gpio.c" file i've included only main.h file and I'm able to compile successfully. But is this the right way to do it? is adding main.h file in all the files cause multiple inclusion of header files?
If I add the main.h file under #ifndef HEADER_FILE in the "adc.c" or "gpio.c" file, i get error while compiling about undefined identifiers.
Multiple inclusion of the same header file is not a problem (and not a noticeable compile-time increase) if each header is appropriately protected with an "#ifndef" as you did.
Note that the name you used in that "#ifndef" must be unique (different in each header file), so the name "HEADER_FILE" is not very good - it would have been better to call it with a unique name, e.g., "INCLUDED_MAIN_H" (and other header files will use other names). Alternatively, all modern compilers support the "#pragma once" command which is better than ifndef in two ways:
You don't need to invent a unique name (and risk that it's not unique)
The compiler doesn't need to read the header file until the end just to look for the "#endif" - once it sees the "#pragma once" and knows this is the second time reading the same file, it immediately stops reading it.
But even though including the same header file is not a problem, including too many headers in a file that doesn't need it is a problem - it increases compilation time, and also increases incremental compilation time: If you change a header file, and a hundred other files include it, the build system (e.g., make) will need to re-compile all of these hundred other files. So usually I would recommend that each source file (.c) should include only the minimal set of header files that it really needs - rather than include some big "main.h" that includes everything.
This is a question of an embedded application, but I imagine the solution is language (C) based and not specific to the embedded compiler (XC16) I'm using.
Problem
I have a number of code files I am abstracting from a single project to create a shared collection of files that can be re-used across multiple projects. These files will require a config.h file in the main application to #define a number of parameters for that project.
Example
Files in project
config.h
#define BUFF_SIZE 4
main.c
#include "config.h"
#include <lib.h>
/*Application Code*/
Files in 'Library' (i.e. another folder NOT in the project structure)
lib.h
extern uint8_t Buffer [BUFF_SIZE];
lib.c
#include "lib.h"
uint8_t Buffer [BUFF_SIZE];
Question
This produces the issue that 'BUFF_SIZE is un-declared in lib.h'. My understanding was that the compiler would start in main.c load in the `#define' values from config.h THEN try to process the lib.h header. But it seems this is not the case.
Do I have to back reference the library to the config.h file? This seems to work, but it then forces the application to have specific file names.
Are there any good examples of how this sort of structuring should take place?
Additional Notes
The same issue arises when I try and map pin outputs for bit-bang functions. i.e.
config.h
#define DATA_OUT LATBbits.LATB4
lib.c
void SetPin(void)
{
DATA_OUT = 1;
}
Cheers :)
C code is compiled on translation unit basis. A translation unit being one single .c file and all the h files it includes. So you must include "config.h" from "lib.h".
You also need to use so-called "header guards"/"include guards" in every header. See
Creating your own header file in C
I have a header file with the declaration of several global variables in the following format:
constants.h
#ifndef CONSTANTS_H
#define CONSTANTS_H
extern unsigned var;
EXPORT_SYMBOL(var);
#endif
constants.c
#include "constants.h"
unsigned var = 10;
foo.c
#include "constants.h"
When I try to compile the kernel module, I get the following error for each respective exported symbol:
WARNING: /home/vilhelm/proj/constants: 'var' exported twice. Previous export was in /home/vilhelm/proj/foo.ko
I suspect that the symbols are being exported every time I include the constants.h header file, but I don't understand why. Shouldn't the include guard in constants.h prevent the EXPORT_SYMBOL(var) from being read multiple times?
Shouldn't the include guard in constants.h prevent the
EXPORT_SYMBOL(var) from being read multiple times?
The include guard prevents the header from being included more than once in the same source file. It can't prevent it from being included via multiple source files. Remember that the objects from all the sources get linked into a single object, and hence the conflict.
Let's say you have another header that is also included in the source files, called foo.h, which in turn includes constants.h. The file constants.c will try to include constants.h twice (once directly via constants.h and again via foo.h). The include guard works here, and constants.h will only be included once.
Same thing will happen with foo.c. It will try to include constants.h twice (once directly via constants.h and again via foo.h). The include guard works here too, and constants.h will only be included once.
But then the two objects, constants.o and foo.o will be linked together, each with its single copy of the EXPORT via constants.h. This adds up to two.
You want to make sure that exports appear in the final link just once. One way to do that would be to take them out of a common file like constants.h, and move them to a file called exports.c.
How does one prevent an inclusion cycle in C? ie. You shouldn't have a.h #include "b.h", which #include's "c.h" which #include's "a.h". I'm looking for a way of preventing this from happening using some sort of C directive.
I had originally thought this would've prevented this from happening:
Contents of a.h:
#ifndef __A_H
#define __A_H
#include "b.h"
#endif // __A_H
Contents of b.h:
#ifndef __B_H
#define __B_H
#include "c.h"
#endif // __B_H
Contents of c.h:
#ifndef __C_H
#define __C_H
#include "a.h"
#endif // __C_H
But it doesn't seem to work.
It does work allright: the files are repeatedly included, but the sections protected by #ifdndef/#define/#endif are not repeated, and that breaks the cycle.
Use your compiler to produce the preprocessed output and look at it for yourself. With GNU CC, you need to use "-E" option on the .c[pp] file, like this:
gcc -E $(CFLAGS) -o foo.i foo.cpp
That should work. It's written correctly in your example and compiles fine for me. Did you mistype something in your actual code, or is it really some other problem you're seeing?
You shouldn't start things out with __, though, as that's reserved for the compiler and/or system libraries. Try some other names for your guards.
Macros with leading underscores are reserved for the preprocessor/compiler.
Try changing __*_H to something more standard.
I use HAVE__*_H.
ya in addition to the above things if you are working on turbo c and you are doing a project with these source files then do not attach the header files which are #included in the source files.And even then if it is not working then try it from command prompt because some compiler options give these errors again and again.so here if the header files contents are between the #ifndef and #endif then there will be no problem even you include both the files. So try removing the header files from the project keeping them in the same directory.bcos u didnt specified environment i specified turbo C because i faced this situation once on turbo C with the header files #included in source file and attached to the project files list then there will be "multiple declaration problem".also after compiling (even with errors) go to external command line and go to directory where that file is stored and try with the filename.exe directly.ok
This works.
Just to be sure, I actually compiled a test.c that included a.h with your 3 header files.
I verified this works for several versions of MSVC, Digital Mars and GCC.
I have a header file x.h which is included by more than one *.c source files.
This header file has some structure variables defined.
I have put multiple inclusion prevention guard at the beginning of the header file as:
#ifndef X_H
#define X_H
...
..
//header file declarations and definitons.
#endif//X_H
On building I get linker errors related to multiple definitions. I understand the problem.
Won't a multiple inclusion prevention guard at the top of header file as I have, prevent multiple inclusions of the header file x.h and thereby avoid multiple definitions of the variables that are there in x.h?
#pragma once does not work on this particular compiler, so what is the solution?
Someone had posted this answer to a similar question. It doesn't seem to work for me. How does this solution work?
If the linker is complaining, it means you have definitions rather than just declarations in your header. Here's an example of things that would be wrong.
#ifndef X_H
#define X_H
int myFunc()
{
return 42; // Wrong! definition in header.
}
int myVar; // Wrong! definition in header.
#endif
You should split this into source and header file like this:
Header:
#ifndef X_H
#define X_H
extern int myFunc();
extern int myVar;
#endif
C Source:
int myFunc()
{
return 42;
}
int myVar;
Header guards are only good for a single compilation unit, i.e., source file. If you happen to include a header file multiple times, perhaps because all headers included from main.c in turn include stdio.h then guards will help.
If you have the definition of a function f in x.h which is included by main.c and util.c, then it is like copying and pasting the definition of f into main.c when creating main.o and doing the same for util.c to create util.o. Then the linker will complain and this happens despite your header guards. Having multiple #include "x.h" statements in main.c is possible of course because of these guards.
Using include guards prevents one compilation unit from including the header twice. E.g. if header B.h includes A.h and B.cpp includes A.h and B.h, everything from A.h would be declared twice in the compilation B.cpp if you weren't using include guards.
Your include guards prevent this from happening, all's fine till now.
But you get multiple definitions at link time, i.e. two compilation units define the same thing, this probably means you got a real definition in your header, use extern for all variables, make sure functions are either inline or are defined in the cpp file.
If the functions aren't large, you can use "inline" before them and the linker won't complain.
Using a multiple inclusion guard prevents compiler errors, but you're getting a linker error. Do you have data definitions in the header file that don't use extern?
Maybe X_H is already defined somewhere else? I just ran into this issue, where Xlib defines X_H in /usr/include/X11/X.h.
To check, you can call gcc -dM -E (if you are using gcc), e.g. in the buildsystem I’m using that works with CC=gcc CFLAGS="-dM -E" make. If the output file contains #define X_H even though you remove it from your file (use Y_H for example), then it is already defined outside your source code.