Resolve the LNK2005 "symbol defined" error that appears

Many users of Visual C + + have encountered link errors such as the lnk2005:symbol already defined and lnk1169:one or more multiply defined symbols, and is usually encountered when using a Third-party library. For this problem, some friends may not know it, and some friends may know it but do not know why, then this article tries to solve all the doubts about it.

As we all know, the process from C + + source to executable will go through two stages: (1) The compiler compiles the source file into assembly code, and then translates the assembler (assembler) into the machine instruction (plus other relevant information) and outputs it to the object file The VC compiler compiles the target file by default suffix name is. obj; (2) the linker (linker) Links each object file (and perhaps several libraries) together to generate a complete executable file.

When the compiler compiles the source file, it divides the global symbol of the source file into strong (strong) and weak (weak) two classes to the assembler, and then the assembler encodes the strength and weakness information into the symbol table of the destination file. So what is strength? The compiler considers that the function and the initialized global variable are both strong symbols, while uninitialized global variables become weak symbols. For example, there is a source file:

extern int errorno;
int buf[2] = {1,2};
int *p;
　　int main()
{

return 0;
}

Where main, buf is a strong symbol, p is a weak symbol, and Errorno is not strong and weak, because it is only an external variable declaration of use.

With the concept of strong and weak symbols, we can see how the linker handles and selects global symbols that have been defined more than once:

Rule 1: Do not allow strong symbols to be defined multiple times (that is, different target files cannot have strong symbols of the same name);

Rule 2: If a symbol in a target file is a strong symbol, in other files are weak symbols, then select strong symbol;

Rule 3: If a symbol is a weak symbol in all target files, select any of them;

It can be seen from the above that multiple target files cannot repeatedly define a function with the same name and a global variable that is initialized, otherwise it will inevitably lead to LNK2005 and LNK1169 two kinds of link errors. However, sometimes we do not find such a redefinition in their own programs, but also encountered such a link error, this is what solution? Well, the problem is a little bit complicated, let me take it slowly.

As we all know, ANSI/C + + defines quite a number of standard functions, which are distributed in many different target files, and if they are provided directly to programmers in the form of object files, they need to know exactly which function exists in which target file. and explicitly specifying the target file name for the link to successfully generate the executable file is a huge burden. So the C language provides a mechanism for packaging multiple object files into a single file, which is the static library. When a developer simply specifies the file name of the library at the time of the link, the linker automatically searches the library for the target modules that the application actually uses, and copies (and only) them from the library to participate in building the executable file. Almost all of the C + + development systems package standard functions into a standard library for developers to use. )。

Library is is convenient for developers, but it is also a source of some confusion. Let's take a look at how the linker resolves (resolve) references to the library.

In the symbolic parsing (symbol resolution) phase, the linker scans all destination files and library files in the order they appear on the command line, from left to right, during which it maintains several collections: (1) Set E is a collection of all the target files that will be merged into an executable file; (2) Set U is a collection of unresolved symbols (unresolved symbols, such as symbols that have been referenced but not yet defined); (3) Set D is a collection of symbols that have previously been added to the target file definition for E. In the beginning, E, U, D are empty.

(1): For each input file in the command line F, the linker determines whether it is the destination file or the library file, and if it is the target file, add F to E, add the unresolved symbols in F and the defined symbols to the U and D collection, and then process the next input file.

(2): If f is a library file, the linker will try to match all the unresolved symbols in U to the symbols defined by each target module in F. If a target module m defines an unresolved symbol in U, then the M is added to E and the unresolved symbols and defined symbols in M are added to the U and D set separately. Repeat this process continuously for all target modules in F until you reach a fixed point, at which point U and D are no longer changing. The target modules that are not added to F in e are simply discarded and the linker continues to process the next input file.

(3): If you add an existing symbol to D in the process, or if you are not empty when all the input files are scanned, the linker complains and stops the action. Otherwise, it merges all the target files in E together to generate the executable file.