I'm trying to write a program in C++ which runs Conway's Game of Life. I think I have everything that I need, but I'm having some trouble with compiling.
The program is composed of four files: gameoflife.h, a header file which contains my global constants and function declarations, gameoflife.cpp, which defines the functions, main.cpp, which uses the functions, and seeds.cpp, which contains a list of predefined seeds to be used.
When I go to compile the application, I seem to have a clash of duplicate symbols between main.cpp and gameoflife.cpp over an array called currGen which is declared in gameoflife.h.
Both main.cpp and gameoflife.cpp include gameoflife.h, which of course is necessary so that they have access to the global constants and function declarations.
The exact error I receive is the following:
duplicate symbol _currGen in /(same_path)/ConwaysGameOfLife.build/Objects-normal/
x86_64/gameoflife.o and
/(same_path)/ConwaysGameOfLife.build/Objects-normal/x86_64/main.o
for architecture x86_64
Command /Developer/usr/bin/clang++ failed with exit code 1
I've looked around on Stack Overflow but haven't found anything which matches my problem. Any help would be greatly appreciated!
You are probably defining the variable currGen in your header file, not just declaring it.
There needs to be exactly one definition, in one .cpp file. The .h file should just declare it, using extern.
This answer goes into much more detail.
Related
I have this question on my review sheet that I cant seem to get but rather than ask you for the answer I would rather like to learn the difference between these specific concepts.
For reference the question is An LC-3 instruction ADD R1,R2, #45 produces an error. It will be caught at a. assembly time b. link time c. run time d. compile time. Rather than just finding out the answer what would rather like to know is what is the difference between these and how do they differ when it comes to error handling?
Using the C programming language as an example the 4 steps to create an executable program Preprocessing, Compiling, Assembling, and Linking.
Compile time
These are generally common and are caused by a malformed user program that the compiler can't process, things such as forgetting a semicolon can cause a compiler error.
Assembly Time
Something went wrong with the assembler. This includes using instructions incorrectly as above, not defining a LABEL but using it in an instruction etc.
Link Time
As part of the C compile process to form an executable many object files generated by the assemble step are linked together. In C programming you can specify that some symbol is defined externally via the extern keyword, other things like function prototypes will tell the compiler a function is defined somewhere.
The linker will resolve where those variables/functions live. If you haven't declared a function/variable and something references it then you will get a undefined reference error. Same for if something is defined multiple times.
Run Time
An error occurred during running your program, this is something such as accessing a pointer that is null, or dividing by zero.
How does a compiler detect duplicate definition across translation unit. Suppose there were a extern const variable declaration in an header file. If this header file was used in more than one translation unit - each having a separate definition - each TU object creation would be successful, however when the final executable is created the error is thrown.
Is there a reference table created to account these duplication while linking each of these TU (during the creation of the executable)?
Any link on this topic would be helpful.
Thanks in advance for your explanation.
Normally this would be detected by the linker, rather than the compiler. The linker can then either coalesce the variables (often required for sloppy C/C++ coding) or report an error.
Yes, the linker builds a list of unresolved external references and then eventually goes on to attempt to resolve them one by one.
i am building a C project with Xcode and when ever i build it it gives me this error:
ld: duplicate symbol _detectLinux in /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/linuxDetect.o and /Users/markszymanski/Desktop/Programming/C/iTermOS/build/iTermOS.build/Debug/iTermOS.build/Objects-normal/i386/iTermOS.o
Thanks!
This means you have defined the same symbol with global scope in (at least) two different source files -- either a function or a global variable called _detectLinux, and apparently in the files linuxDetect.c and iTermOS.c.
How to fix it depends on how you intend to use this symbol:
If you meant to define it in one file and use it in the other file, declare it extern in the other file.
If you only intend to use the symbol in the file that it is declared in, you can declare it static.
If the symbol is defined in both files, you can rename the symbol in one (or both) files.
If _detectLinux is a function, one common way to get this problem is to define it in a header file but forget to mark it inline. This would cause it to generate the function code in each file that includes the header (presumably _detectLinux.c and iTermsOS.c).
Alternately perhaps you copy-pasted the entire body of the function between the two source files instead of simply declaring the function in iTermsOS.c where I expect it's being called.
Well, that's not much information to go on. As the error says, the symbol _detectLinux is included in both linuxDetect.o and iTermsOS.o and when you try to link them together, there is a conflict since the linker does not know which of the two symbols to use. This might happen if you, for example, have a global variable with that name in a .h file which is used to build both files instead of declaring it in one place and declaring it as "extern" in the .h file.
What you need to do is look at where the symbol _detectLinux is originally declared, then trace through the dependencies for both linuxDetect.o and iTermOS.o to see why it is being included publicly in both.
I am trying to save space in my executable and I noticed that several functions are being added into my object files, even though I never call them (the code is from a library).
Is there a way to tell gcc to remove these functions automatically or do I need to remove them manually?
If you are compiling into object files (not executables), then a compiler will never remove any non-static functions, since it's always possible you will link the object file against another object file that will call that function. So your first step should be declaring as many functions as possible static.
Secondly, the only way for a compiler to remove any unused functions would be to statically link your executable. In that case, there is at least the possibility that a program might come along and figure out what functions are used and which ones are not used.
The catch is, I don't believe that gcc actually does this type of cross-module optimization. Your best bet is the -Os flag to optimize for code size, but even then, if you have an object file abc.o which has some unused non-static functions and you link statically against some executable def.exe, I don't believe that gcc will go and strip out the code for the unused functions.
If you truly desperately need this to be done, I think you might have to actually #include the files together so that after the preprocessor pass, it results in a single .c file being compiled. With gcc compiling a single monstrous jumbo source file, you stand the best chance of unused functions being eliminated.
Have you looked into calling gcc with -Os (optimize for size.) I'm not sure if it strips unreached code, but it would be simple enough to test. You could also, after getting your executable back, 'strip' it. I'm sure there's a gcc command-line arg to do the same thing - is it --dead_strip?
In addition to -Os to optimize for size, this link may be of help.
Since I asked this question, GCC 4.5 was released which includes an option to combine all files so it looks like it is just 1 gigantic source file. Using that option, it is possible to easily strip out the unused functions.
More details here
IIRC the linker by default does what you want ins some specific cases. The short of it is that library files contain a bunch of object files and only referenced files are linked in. If you can figure out how to get GCC to emit each function into it's own object file and then build this into a library you should get what you are looking.
I only know of one compiler that can actually do this: here (look at the -lib flag)
I have a question regarding gcc. Why I get an error of unused variable when I define the variable locally in a function but not when the variable is global in a unique file?.
I can understand that it can be use for someone else, but to do that then I need to put the external word right?
Thanks in advance.
The compiler has no way of knowing if a global variable is used - it could be used from a compilation unit written in a completely different language, for example.
If by "global in a unique file", you mean "int x;" outside of any function, the it's not the compilers job to detect that, the variable needs to be available to the linker in case another compilation unit needs it (such as errno).
If you meant "static int x" where it's not made available to the linker, this is probably just a choice made by GCC. I don't believe compilers are required to notify of this and it does no real damage other than wasting a few bytes in your address space.
Because global variables can be used on any other place that the compiler cannot known. For instance on a external library o program.
Unused locals can be determined by the compiler. Unused globals can only be determined by the linker, since they can be shared across object files.
In general, the linker doesn't do warnings for code-gen.
When the variable is global, the compiler has not full visibility across all the compilation units in the project - the variable could be modified in another compilation unit. The linker is able to tell that it is unused, probably it will remove it from the object file.
Because if it's global it can be used by another module that gets linked in later.
It's a common idiom to have all your globals defined in a single file. That file may not even have any code, much less code that uses all the variables.
I have encountered the same question when I build the dalvikVM in android2.3 and I got the key of the point. It is because that the parameters of the compiler is too strict:
LOCAL_CFLAGS += -Werror.