I get the below error. Why do I get it?
Duplicate symbol _main in:
/Users/AlexBomnd/Library/Developer/Xcode/DerivedData/Backpack-gcnxteerautalugwepzkevaqgtxe/Build/Intermediates/Backpack.build/Debug-iphonesimulator/Backpack.build/Objects-normal/x86_64/main.o
/Users/AlexBomnd/Library/Developer/Xcode/DerivedData/Backpack-gcnxteerautalugwepzkevaqgtxe/Build/Intermediates/Backpack.build/Debug-iphonesimulator/Backpack.build/Objects-normal/x86_64/AppDelegate-2D6246B5E95B9D9F.o
ld: 1 duplicate symbol for architecture x86_64 clang: error: linker
command failed with exit code 1 (use -v to see invocation)
Both main.m and AppDelegate.m (or perhaps AppDelegate.swift) contain the function main. Only one main function can exist per program, as it's the sole entry point for any C, Objective-C, or Swift program.
More information:
Compilation of a program is actually a series of a few separate steps.
Each project is composed of a series of compilation units. In Objective-C, each .m file is a compilation unit. In C, it's it's .c file. In Swift, the combination of all .swift files is one module (equivalent to a compilation unit for the others). Each of these is compiled independently, to produce a series of object files (.o, as you see in your error).
Your program has compiled and successfully made it past this step.
After compilation of the individual compilation units, the produced object files are linked together by a program called the linker, to produce the file program. During the linking step, the linker runs into an error because both the main.o file (the object compiled from main.m) and the AppDelegate-2D6246B5E95B9D9F.o file (the object compiled from AppDelegate.m or AppDelegate.swift) contain a definition for the symbol _main. The linker doesn't know which of the two to choose, so it raises an error.
Related
I recently ran into a problem linking one of my c++ projects. I was missing a virtual method's implementation, and g++ gave me a pretty unhelpful error message. All it said was 'undefined reference to vtable for [class]'.
I ended up finding the missing method by running 'nm -C [so file] | grep [class name]' and comparing the methods to the header, but I can see this being difficult for non-trivial classes.
Is there a linker option or utility that will do this automatically? (for my Makefile ideally)
Im using MPLAB X v5.25 and XC8 v2.10
When building my code, I encounter an error that says error: (500) Undefined symbols
and enumerates certain functions that are contained in other C files linked with headers.
*:0:: error: (500) undefined symbols:
_OneWireTemp(dist/default/production\firstpic.X.production.o)
_sending(dist/default/production\firstpic.X.production.o)
_USART_Init(dist/default/production\firstpic.X.production.o)
(908) exit status = 1*
The functions are from the one wire library, HTTP GPRS library and USART library.
Any help would be appreciated
[...] other C files linked with headers. [...]
Header files do not link C files - they simply declare symbols. You get undefined symbols when the linker cannot match the symbols referenced in the code it has been asked to link. The most likely cause being that you have not actually linked the object code for each C file that the compiler compiled.
That is to say, each C file must be separately compiled to create an object file. The purpose of the headers in this process is to make visible to the compiler the symbols that will be defined in separate object files.
The object files generated by separate compilation are then passed to the linker which resolves the external references in one object file with definitions provided in other object files (or static libraries included in the link).
It is the linker that is issuing the undefined symbols diagnostic, almost certainly because you have not separately compiled the C files and passed the generated object code to the linker.
In most IDEs (and I don't believe MPLAB X is any different), you add the C source files to a "project", and the IDE's project manager will manage the separate compilation and linking for you. So it is likely that you have simply omitted to add the C sources to your project. No amount of header file inclusion is going to solve this issue, header files are included by the pre-processor (before compilation and linking).
I'm wondering how I would go about making CMake produce an error, or at least a warning, when the linker cannot find symbols that are referenced in a source file?
For example, let's say I have foo.c:
#include "bar.h" //bar.h provides bar()
void foo(void)
{
bar()
return;
}
In the case that I am building a static library, if i am not smart about how i have used my add_library() directive, the default behavior seems to be to not even give a warning that bar is an unreferenced symbols in foo's object archive file (.a)
The CMAKE_SHARED_LINKER_FLAGS compiler flags for building shared libraries should get the compiler to do what you want.
set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined")
On Unix systems, this will make the linker report any unresolved symbols from object files (which is quite typical when you compile many targets in CMake projects, but do not bother with linking target dependencies in proper order).
Source: http://www.cmake.org/Wiki/CMake_Useful_Variables
There's the -z now for the GCC linker these days, but yeah, this isn't CMake's problem.
The most fool-proof way I've found only works on shared libraries, but what you do is basically write a test for each shared library and it then just does dlopen(path, RTLD_NOW) (and similar for Windows) and then use its return value as the test return value. To get a list of all shared objects, I have a wrapper function around add_library which adds all shared libraries to a global property which then is used to generate the tests dynamically. I remember there being some way to tell if a target was shared or static, but I'm not finding it the docs right now.
I have a CarClass.h file that declares CarClass.
I then #import this CarClass.h file into my CarClass.m file where I of course then go on to implement all my CarClass methods.
Finally, my CarAPP.m file (which contains the main) ALSO #imports CarClass.h - and everything works just fine.
Ss there are actually no problems there :-)
However, I'm not sure I understand WHY it works - cause the linkage seems a little off: if CarAPP.m imports ONLY the CarClass.h file - without also importing the CarClass.m file, then where does it GET or SEE the implementations from?
Is it the case that once the ".m" file - which imports the ".h" file - is compiled, then the two files (.h and .m) are sorta forever linked or something?
I just don't get it...
The compiling process is split in different phases, and #import directives are interpreted long before any linkage occurs.
When you give code files (.c, .m) to your compiler, it will try to generate a code object file (.o) from it; that is, a binary representation of your code. This file is not yet executable because it needs more information. Especially, it's not linked to any other file. Header files, supposed to contain only declarations and no definition, typically don't get their own matching .o file.
After all your code files have been made into code objects, the compiler will put them all together and invoke the linker. The linker will resolve all external references, and then will produce an executable file.
The point is that header files tell the compiler that a function or method exists somewhere. This is enough at the current phase of compilation to produce object files: the compiler just needs to be told what exists, not where's the definition. Only when you actually link you need to know this.
Since all your code object files get packaged together, your whole program gets access to everything that was publicly declared within itself. This is why you don't need to explicitly "link" CarAPP.m against CarClass.m.
It's also possible to mislead the compiler and declare functions in header files that not defined anywhere. If you use them in your program, the first phases of compilation will go just fine (no syntax error, no "undeclared function") but it will break at link-time, since the linker won't be able to locate the nonexistent function.
When you have #import whatEver.h, the pre-processer tries to finds the corresponding file in the default location. If found, it just pastes the content of the whatEver.h to the corresponding source file where ever you use #import whatEver.h. So, to get a final executable, your source files should pass Pre-Process, Compile and Linker stages.
When you have CarClass.h in CarAPP.m, the linker goes to find the implementations of CarClass.h in CarClass.m. Strictly, speaking it goes to find the definitions in CarClass.o. Compiler is happy as long as there are declarations of what you use and the linker is happy as long as there are definitions for the declarations when you intend to use.
When you import CarClass.h to your CarAPP.m, you are saying to linker to find the CarClass.h method implementations in CarClass.o. So, your final executable is a combination of CarAPP.o and CarClass.o. To understand more about how compiling and linking is done, Program Compilation. Though link is C/C++ specific, it should give you an idea.
I read this Q&A: What does the -all_load linker flag do?
So, does this affect runtime loading? Does final program load unnecessary symbols or only for link time?