I have been having these really odd problems with Visual Studio 2010. At this point, the behavior is so erratic that I really wish I did not have to use it for CUDA (I know I don't have to, but it is hard not to use it).
One of the many problems I have been having with really basic stuff is header files being included more than once. For example:
//vars.cuh
#if !defined(VARS_cuh)
#define VARS_cuh
#include <cuda.h>
#include <cuda_runtime_api.h>
int* kern_xstart, *kern_xend, *kern_ystart, *kern_yend, *kern_zstart, *kern_zend;
/* more variable definitions */
#endif
I then include this file in most of my source files:
//source_file.cu
extern "C"{
#include "vars.cuh"
/* more includes of my own headers */
#include <cuda.h>
#include <cuda_runtime_api.h>
}
/* source file body */
The VS 2010 compiler puts out errors like this: "error LNK2005: foo already defined in other_source_file_I_wrote.cu.obj"
Why is it doing this? Also, to kill two birds with one stone, with this setup, I also have problems with writing a function in source_file.cu, and then prototyping it in vars.cuh. The problem arrises that vars.cuh can't see the definition, even though I am clearly including vars.cuh in source_file.cu!
Thank you!
The header file is being compiled multiple times because, as you say, you include this header file in most of your source files. Those global variables are included in multiple source files and thus are defined in every source file that includes the header. When the linker links all of the object files together, it finds multiple definitions of those variables, hence the error.
If you want to share global variables across multiple source files, declare them as extern in the header, then define each of them once in one source file.
This isn't a problem with Visual Studio or the Visual C++ compiler, it's how C works.
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 am just starting out with Segger Embedded Studio. Right now trying to call a function of a included header file. The file seems to be included since it shows up in the dependencies. For now I simply included the header and C-File in the project directory.
The included Header- and C-Files are simply:
//##### Header-File ######
#ifndef TEST_H_
#define TEST_H_
void printText(void);
#endif //TEST_H_
and:
//###### C-File #########
#include <test.h>
#include <stdio.h>
#include <stdlib.h>
void printText(void)
{
printf("Hello");
}
But when I try to call the printText Function in my main I get the error:
"Undefined Symbol: printText".
Why is the function not recognized?
"Undefined symbol" is a linker error. You are not linking the object code containing the definition of printText().
It is not an issue with the header file; including a header file does not cause the associated code to be linked - that is just the declaration so the compiler knows what the interface looks like. It is the linker than combines the separately compiled object code to form a program. You have not told the linker to use the object code containing printText(), and you have not told your IDE project to compile it to generate that object code.
The project tree clearly shows that only main.c is included in your project; you need to add the C file containing printText() too.
The concept of separate compilation and linking is what you need to grasp here.
Thank you Clifford for your answer. You are right I had some miss-conceptions about which files will be linked while building the project. In the special case of segger embedded studio there are, as I know by now, two ways to reference extern files.
Adding the files to the sources files folder is straight forward, but must be done separately for each project you want to use the respective files.
For frequently used files it is beneficial to create a dedicated library solution. Such a library can then be imported to any solution by choosing "add existing project". This will add all files of the library to your current solution (and show them in the project-tree). Now click the tab project -> dependencies. Your library should show up here. By acitivating the check box the linker will compile the referenced project upon builing your solution, allowing for the usage of your library functions.
Adding and linking library-project to a current solution
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.
I'm having an issue with compiling code for Arduino if the code is in multiple files. What I have been doing in the past is have a script concatenate the files in another directory and make the project there. I would like to be able to compile directly from my build folder without having to jump through hoops of making sure everything is defined in the right order, etc.
I'm using avrdude to compile from Linux command line, because the Arduino IDE doesn't work very well with my window manager. When I make with multiple files (with appropriate #include statements, I get errors of the following nature, but for all of my methods and variables.
./../lib/motor.ino:3:21: error: redefinition of ‘const long unsigned int MOVE_DELAY’
./../lib/motor.ino:3:21: error: ‘const long unsigned int MOVE_DELAY’ previously defined here
The only other place that MOVE_DELAY is used is inside the void loop() function, and it doesn't redefine it there. The code also compiles fine if concatenate it into one file and run make in that directory, but not if they are in separate files with includes.
I believe your problem is solvable by declaring the objects with the "extern" prefix or external. For example. I often use the SdFat library, in which it is included in both my main sketch and instanced in other libraries.
/**
* \file test.ino
*/
#include <SdFat.h>
#include <foo.h>
SdFat sd;
...
Where I also use the same object in other libraries, such as foo.h.
/**
* \file foo.h
*/
#include <SdFat.h>
extern SdFat sd;
...
If it was not for the prefix of "extern" it would error like yours, as "sd" can not exist twice. Where the extern prefix tells the linker don't make a new instantiation, rather link to the externally instance elsewhere.