At compile time, the compiler exports each global symbol to the assembler as either strong or weak, and the assembler encodes this information implicitly in the symbol table of the relocatable object file. Functions and initialized global variables get strong symbols. Uninitialized global variables get weak symbols.
For the following example programs, buf, bufp0, main, and swap are strong symbols; bufp1 is a weak symbol.
Given this notion of strong and weak symbols, Unix linkers use the following rules for dealing with multiple defined symbols:
Rule 1: Multiple strong symbols (with same variable name) are not allowed.
Rule 2: Given a strong symbol and multiple weak symbols, choose the strong symbol.
Rule 3: Given multiple weak symbols, choose any of the weak symbols.
For example, suppose we attempt to compile and link the following two C modules:
In this case, the linker will generate an error message because the strong symbol main is defined multiple times (rule 1):
$ gcc foo1.c bar1.c /tmp/cca015022.o: In function ‘main’: /tmp/cca015022.o(.text+0x0): multiple definition of ‘main’ /tmp/cca015021.o(.text+0x0): first defined here
Similarly, the linker will generate an error message for the following modules because the strong symbol x is defined twice (rule 1):
However, if x is uninitialized in one module, then the linker will quietly choose the strong symbol defined in the other (rule 2) as is the case in following program:
At run time, function f() changes the value of x from 15213 to 15212, which might come as a unwelcome surprise to the author of function main! Notice that the linker normally gives no indication that it has detected multiple definitions of x.
$ gcc -o gfg foo3.c bar3.c $ ./gfg x = 15212
The same thing can happen if there are two weak definitions of x (rule 3):
The application of rules 2 and 3 can introduce some insidious run-time bugs that are incomprehensible to the unwary programmer, especially if the duplicate symbol definitions have different types.
Example : “x” is defined as an int in one module and a double in another.
$ gcc a.c b.c -o geeksforgeeks $ ./geeksforgeeks x = 0x0 y = 0x80000000
This is a subtle and nasty bug, especially because it occurs silently, with no warning from the compilation system, and because it typically manifests itself much later in the execution of the program, far away from where the error occurred. In a large system with hundreds of modules, a bug of this kind is extremely hard to fix, especially because many programmers are not aware of how linkers work. When in doubt, invoke the linker with a flag such as the gcc -fno-common flag, which triggers an error if it encounters multiply defined global symbols.
Source : http://csapp.cs.cmu.edu/public/ch7-preview.pdf
This article is contributed by Sahil Rajput . If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to firstname.lastname@example.org. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please write comments if you find anything incorrect, or you want to share more information about the topic discussed above.
- Internal Linkage and External Linkage in C
- Why variable name does not start with numbers in C ?
- Redeclaration of global variable in C
- Storage Classes in C
- Data Types in C
- Variables and Keywords in C
- Interesting Facts about Macros and Preprocessors in C
- Commonly Asked C Programming Interview Questions | Set 1
- Use of bool in C
- Complicated declarations in C
- Scope rules in C
- Const Qualifier in C
- puts() vs printf() for printing a string
- How are variables scoped in C - Static or Dynamic?
- Understanding "extern" keyword in C