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 .
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'm new to programming, and I'm currently working on a project that got a little too big to keep in a single cpp file, so I decided to split it up into its constituent parts in different cpp files.
The project has 3 cpp files;
main.cpp, TwinCameraCapture.cpp, FaceCalibration.cpp,
All of the meat of the code is in FaceCalibration.cpp and TwinCameraCapture.cpp, with main.cpp looking like this:
#include "FaceCalibration.cpp"
#include "TwinCamCapture.cpp"
int main ()
{
FaceCalibration();
TwinCameraCapture();
}
With FaceCalibration and TwinCameraCapture being the primary functions within their respective .cpp files.
Now, I know I'm doing something wrong here, I just don't know what exactly it is. The error I get when trying to compile is:
Apple Mach-O Linker (Id) Error
Command /Developer/usr/bin/llvm-g++-4.2 failed with exit code 1
Could someone please explain what I've done wrong and how to fix it, or point me to a guide that will do so?
Thanks
EDIT:
The full error message is:
ld: duplicate symbol getWindow(cv::Rect_<int>) in
/Users/facebooth/Library/Developer/Xcode/DerivedData/FullProgramTest-
awrdeznffntuoacjytwewfbjdmza/Build/Intermediates/FullProgramTest.build/Debug/FullProgramTest.build/Objects-normal/x86_64/FaceCalibration.o and
/Users/facebooth/Library/Developer/Xcode/DerivedData/FullProgramTest-
awrdeznffntuoacjytwewfbjdmza/Build/Intermediates/FullProgramTest.build/Debug/FullProgramTest.build/Objects-normal/x86_64/main.o for architecture x86_64
Command /Developer/usr/bin/llvm-g++-4.2 failed with exit code 1
Generally, you don't use .cpp files as #include. You should have a .h file that is included.
It would be helpful to know what your actual error message is, rather than just that "it failed", but I suspect it's "duplicate identfier " or some such - because your IDE is already compiling and linking your file TwincameraCapture.cpp, and then you go and make that piece of code part of your main source, whicn means the compiler generates the same code twice, and the linker says "Which one of these do you mean?" when it sees two functions with exactly the same name.
Simply rename the .cpp file that doesn't include the main() function to a .h file and then adjust the #include appropriately and it will work. I haven't got far enough along to get to headers to know why it is like that in xCode or anything but I do know that this works.
I'm a novice C++ programmer and I only know how to program in visual studio, but my PC crashed and I only have mac Xcode available.
I wrote a .cpp like in visual studio, but when I had it build, it gave me this error..
ld: duplicate symbol _main in /Users/karen/Desktop/BD/build/BD.build/Debug/BD.build/Objects-normal/x86_64/bd1.o and /Users/karen/Desktop/BD/build/BD.build/Debug/BD.build/Objects-normal/x86_64/main.o
Anyone know what to do?
This error is telling you that you have defined "main" in two separate files: (probably "bd1.cpp" and "main.cpp"). If you didn't create the file "main.cpp" (or "main.cc"); it's possible that XCode created a sample "main" for you when you set up the project.
A program can have only one function named "main", so you need to get rid of one of them...
Its a linker error, so you can't really "debug" this.
Can we see some code? bd1 and main have a duplicate symbol - so u use maybe same variable/function names without namespaces? Its also possible, that you need to "cleanup" before you try to build (old symbols in object files) - but its like guessing without seeing your code...
Either bd1.cpp or main.cpp should go, as they both have a main function. There can only be one main function in a C/C++ program. Most likely main.cpp was automatically created for you when you created a new Xcode project for existing codebase. So search for main.cpp/main.c in your project and remove it.
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.
I'm using MSVC++ 6 to build a very large project. Some of the source files in this project are shared with a small utility that we use for maintaining the application. Previously, this small utility required linking against many libs from the main app and also required the main app's DLLs at runtime. I was tasked with removing these dependencies, which sounded pretty simple... unfortunately, the precompiled headers used in the main app are causing me a lot of trouble.
I first reworked all the files in the utility to explicitly include everything they need and then I removed the #include directives for the PCH (this removed 95% of the unnecessary dependencies for the utility). This works great for compiling the utility. Now, however, compiling the main app gives me errors about missing precompiled header directives. I thought "great, I'll just conditionally include the PCH". This does not seem to work... I get "unexpected #endif", as mentioned here. My next thought was to turn off PCH in the main app for the three source files that are shared between the utilty and the main app. This compiles successfully, but I get a bunch of errors that look like this during linking:
tls7d.lib(tls707d.dll) : error LNK2005: "public: unsigned int __thiscall RWCString::length(void)const " (?length#RWCString##QBEIXZ) already defined in stripledescypher.obj
AFAICT, all of the multiply defined symbols are ones that I explicitly include in the shared files to avoid the need for the PCH. My hunch is that since I'm linking those 3 files into the same DLL as the PCH .cpp file, they're compiled in multiple places. Is there any way out of this mess? I'll try just about anything...
When the compiler finds a definition of a symbol X when processing a compilation unit, it will create a hint for the linker: X is in here!
The compilation of two source files, both #includeing a header with a definition (i.e. not a mere declaration) will result in two object files defining the same symbol. The linker will find a symbol multiply defined.
So it appears that your stripledescypher object file includes a definition of the WCString::lenght()const method. This may be due to the function body being defined in the class' header or something the like.