I have the following header files:
https://gist.github.com/wemakeweb/5501443
and the compiler always reports "Unknown Type name Class". I have included Forward Declaration, to break circular including , where i think i have to. What did i forget?
Edit: i put it all in one header file, and the compiler still reports "expected ; after top level declarator"
https://gist.github.com/wemakeweb/5583500
Edit 2
Now im getting linker errors. "Undefined symbols for architecture x86_64"
Solved, Problems were
Circular Including
main.c instead of main.cpp
the actual code was in a static lib which was not linked properly
This error? error: unknown type name ‘class’
You're probably compiling it as C rather than C++.
Make sure your source file has a .cpp extension, and than any relevant compiler flags are set correctly. (It helps if you include the exact error message and line numbers. Don't try and retype, just cut+paste.)
You have at least one cyclic include dependency between Feld.h and Figur.h. The forward declarations have no effect if you also include the headers. Just remove the includes.
Related
I have a bunch of arm assembly, C and C++ files. gcc is trying to link them, but these are for an embedded project.
I am not using any external libraries, all code that is being used was written by me. An error seems to happen because I have a function called int kernel_main(void) defined in main.c that is trying to call set_LED(int value) defined in mailbox.cpp which includes the header mailbox.h (I did include the header in the main.c file).
The exact error is:
undefined reference to `__aeabi_unwind_cpp_pr1'
The way I am making my project is:
-compile all source files (.s, .c, .cpp) into object files (.o) without linking (-c), then link them all together with the use of a custom linker script.
Edit: I am going to add some information to make things more clear.
First changing all files so that all of them are C files (no cpp extensions) yields:
undefined reference to `set_LED'
It is unlikely that the issue itself is name mangling an it probably has nothing to do with CPP and C differences.
The problem is very likely to be a linker issue
This is the build process:
Compile c files, Example:
arm-none-eabi-g++ -O0 -march=armv8-a source/MainFiles/mailbox.cpp -nostartfiles -c -o objects/MainFiles/mailbox.o
(Compiling a C++ file would be identical except for the use of g++ instead of gcc)
Link everything:
arm-none-eabi-ld object1 object2... -o build/kernel.elf -T ./source/kernel.ld -I include_directory_1 -I include_directory_2 -L include_directory_1 -L indlude_directory_2
Include directories are all directories under the current one
Edit:
The error came back. Ignore the parts of this question relevant to name mangling. The error I need to fix is:
./objects/Hardware/mailbox.o:(.ARM.exidx+0x18): undefined reference to `__aeabi_unwind_cpp_pr1'
So far all I know is that this has something to do with unwinding the stack and exceptions. It seems the function is defined in libgcc. However I have used -nostdlib, I have omitted it, and in both cases the error persists. I have tried changing file extensions to .c whenever possible and to .cpp whenever possible, alas the error is always there.
It got fixed only as long as I had exactly 1 cpp file and the rest of my files were C files (this is no longer true, I tried). What triggered the error again was that I was refactoring the code and I wanted to move a couple of functions to new files.
In other words, without deleting a single file, declaring a function named wait(uint32_t time) in mailbox.cpp works, declaring it in a file called time.c (or cpp) with it's respective header declaration and including the header in mailbox.cpp breaks things. Note I don't delete the files when moving the function I simply delete the function declaration inside each file.
Adding a stub like this:
void __aeabi_unwind_cpp_pr1()
{
}
Fixes the problem and the code works. But I don't like this solution. I don't want a useless stub being called mysteriously in my code. I don't need nor want this function in my current implementation, how can I tell the compiler or the linker that they are to omit whatever they are doing that requires this function?
The solution is very simple. As it turns out exceptions are enabled by default (which is what generates the code that calls __eabi_unwind_cpp_pr1). To disable them all that is needed is to pass:
-fno-exceptions as an argument to the gcc/g++ compiler and the problem is solved.
You have a reference to this function that belongs to the C++ runtime of GCC. It's part of the exception handling. Whatever you are doing, sounds a little crazy, but anyway you can do this if you really know what you are doing. You must link against the C++ runtime libraries. That's it. Link against "libstdc++".
About the set_LED I also believe it's just about the C++ mangling, just as Justin J mentioned in the other answer.
I have seen this when mixing C and C++. Because of name mangling, the symbols will have different names internally depending on the type of the source file.
If the source for 'set_LED'is a c file, use the following in the header around the prototype and see if it helps.
#ifdef __cplusplus
extern "C" {
#endif
// function prototypes here
#ifdef __cplusplus
}
#endif
Please also add prefix "-shared" without quotes to -fno-exceptions. I am using ARM GCC version
I've been looking for solutions for this problem but them didn't work for me! I've been having a lot of problems compiling programs.
When I'm trying to execute a program in Xcode appears:
duplicate symbol _main in /Users/LauraChaparro/Library/Developer/Xcode/DerivedData/Busqueda-ercduihvfosqcoczkrgljkkmgxam/Build/Intermediates/Busqueda.build/Debug/Busqueda.build/Objects-normal/x86_64/Uno.o and /Users/LauraChaparro/Library/Developer/Xcode/DerivedData/Busqueda-ercduihvfosqcoczkrgljkkmgxam/Build/Intermediates/Busqueda.build/Debug/Busqueda.build/Objects-normal/x86_64/main.o for architecture x86_64
I don't understand why this happens! Is a C++ project... Or if you can recommend me another IDE I'll be really thankful!
It looks like you are defining a main in some of the code used to make the Uno.o object file. You can only have one main, so objects used to build libraries should not define a main. This should only be defined in the application itself.
This a linker error and it likely you would encounter it with other IDEs. You need to find where in Uno.o the main is defined and remove it.
The error you have there is a linker error. It tells you exactly what is wrong. The linker has found out that it can find the symbol *_main* defined more than one time looking through the object files. This makes it impossible for the linker to create an executable of your object files, as it have no way of telling which symbol you want to use. It continues to tell you where it found the two symbols.
Once in the Uno.o file (which I will assume come from compiling the Uno.cpp file)
another from the main.o file (from the main.cpp file)
This means, that somehow the linker can find the symbol for the main method in both files.
This could happen by:
Defining a main function both in the Uno.cpp and main.cpp
Having placed a non inline main definition in a header and including this both in the Uno.cpp file and the main.cpp file (or an include that includes another include and so on.)
As your request for another IDE I would like to remind you that neither compiler errors or linker errors are errors in the IDE, in an overwhelming number of cases the problem is that the user of the IDE has done something wrong.
This happened to me once, Make sure you include your .h file instead of your .c file in the file you don't expect your main function to be. I had my include statement having .c file and it produced the same issue .
I have a file SpreadSheetCell.h and SpreadSheetCell.cpp.
I have another file SpreadSheet.cpp which includes SpreadSheetCell.h .In this case it is giving me errors like "undefined reference to SpreadSheetCell:SpreadSheetCell()" etc. But when i try to include SpreadSheetCell.cpp instead the errors are gone. Is it not common to include the header files rather than the cpp files? What can i possibly be doing wrong?
That is a linking error and means that you are not including a sourcefile that has the definition for SpreadSheetCell:SpreadSheetCell() when compiling.
You are probably missing SpreadSheetCell.cpp in the command line you use, e.g. something like:
g++ -o myBinary SpreadSheet.cpp SpreadSheetCell.cpp [...more files?]
It's never a good idea to include source code. Always only include header files.
I can't look in your file(s), however, I think that SPreadSheetCell.h includes a file (SpreadSheet.h maybe?) so that a circular dependency exist.
The best way is to make a graph of the files that are included (in both cpp and h files). If there is a 'circle' somewhere you have found the problem. In that case you should remove one link so the circle is broken or split files up in smaller files (also to remove the circle).
(with 'circle' I mean e.g. a file A including B including C including A again.)
Ensure your SpreadSheetCell.cpp has a #include "SpreadSheetCell.h", if not show your code and your compiling commands!
I get this error while compiling:
error: aggregate 'X x' has incomplete type and cannot be defined
I have three classes in 6 different files(header file + 3 implementation files). when I try to compile all these classes with a main, It gives me the above error. I am not including any header file in other header files, I am doing that in implementation files. So, I think its not a case of "cross reference". I am not sure what is the problem with my code can anyone help me in that?
Thanks
Somehow, that class isn't being defined when it needs to be.
Firstly, make sure the header has actually been included. Further, make sure you have include guards, and that you don't have circular includes and recursive definitions. Aside from that, without the code we cannot give specifics.
I came across this error trying to compile a shared object from 2 sets of objects. The first set contains one .os object compiled from one cpp file generated by SWIG. The second set is contains all of the .so files from the individual files that make up the interface to be wrapped.
$g++ -shared *.os -o Mathlibmodule.so
ld: duplicate symbol std::vector<int, std::allocator<int> >::size() constin Mathlib_wrap.o and Capsule.o
The swig c++ wrapper (Mathlib_wrap.o's source file) is machine generated and nasty to look at, with lots of #defines to make it extra hard to trace. It looks like the redefinition is present in all of the object files in the second set. I've traced through the headers included in all those files, and the seem to be #pragma once'd.
What advice do people have for tracking down what/where the problem is?
I'm going to assume that you've properly #ifndef/#define blocked all of the header files in your C++ library, after that I'd check your .i file to make sure you aren't actually duplicating some declaration there somehow. Maybe try importing a small small piece of the library first or something.
I have run into issues like this before, but its always turned out to be something silly I'd done. Nothing specific I'm afraid.
Post the .i file maybe, donno.
When in doubt, assume that the error means what it says: Actual code was generated for vector<T>::size within each of those object files. This of course seems very unusual because you would expect the function to be expanded inline in each file it was being used in.
If it weren't std::vector the first thing I would say is that a function defined in a header wasn't marked inline correctly. The compiler would generate the code in each source file that included that header. What version of g++ are you using, and are you using a custom standard library/vector implementation?
One thing to check is to compile with optimization on (-O2) and see if that causes it to inline the calls within creating an actual function.
Another possibility is that you're including two different versions of the vector include, and violating the one definition rule. At that point I wouldn't rule out a linker error such as you're seeing.