+23  A: 

Because you link the startup files to your program, which contains (usually) assembler code that calls your main. If main were static, that code wouldn't be able to call main.

external linkage means that other so-called translation-units can see your symbol declared extern in its own translation-unit. So, your main is extern, and it will have an entry in its translation-units symbol table that states its address. Other translation-units will then be able to jump to that address when they want to call main.

static linkage means your symbol is strictly translation-unit local. This means other translation units will not be able to see that symbol. Thus, symbols with static linkage can occur in different translation units multiple times, and they won't clash with each other because they are local.

Edit: Generally, files generated by the compiler from translation units are specific to that particular compiler. For gcc on linux, often the ELF object format is used. You can view its symbol table using readelf -sW <file>.o (simple test-file below):

test.c

void bar(void);

static int foo(void) {
    return 1;
}

int main(void) {
    bar();
    return foo();
}

Here is the output of readelf:

Symbol table '.symtab' contains 10 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
     0: 00000000     0 NOTYPE  LOCAL  DEFAULT  UND
     1: 00000000     0 FILE    LOCAL  DEFAULT  ABS test.c
     2: 00000000     0 SECTION LOCAL  DEFAULT    1
     3: 00000000     0 SECTION LOCAL  DEFAULT    3
     4: 00000000     0 SECTION LOCAL  DEFAULT    4
     5: 00000000    10 FUNC    LOCAL  DEFAULT    1 foo
     6: 00000000     0 SECTION LOCAL  DEFAULT    6
     7: 00000000     0 SECTION LOCAL  DEFAULT    5
     8: 0000000a    36 FUNC    GLOBAL DEFAULT    1 main
     9: 00000000     0 NOTYPE  GLOBAL DEFAULT  UND bar

You see the main function, and a static foo function, called by main. Also there is a function called which is not defined in the file, but which is defined in another object file. As the object file wasn't finally linked yet, the functions don't have final addresses assigned yet. After the final link, these will be arranged into the executable and will have addresses assigned. The object file has entries for calls to not-yet defined functions, so that when the file is linked, those call instructions can have the final addresses stored (readelf -r <file>.o):

Relocation section '.rel.text' at offset 0x308 contains 1 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
0000001c  00000902 R_386_PC32        00000000   bar
Johannes Schaub - litb
how can we analyse those translation units.Can we see them in the form of tables or graphical forms for every file?if its not possible then in which compiler generated file or attribute file we can know the attribute of a function.?
Manoj Doubts
Your tools vendor will have a utility that does this. E.g. objdump (Unixy), dumpbin (MSFT), tdump (Borland/CodeGear/Embarcadero)
Barry Kelly
what is it for gcc?
Manoj Doubts
ok ok thank you guys for your explanations.It helped me a lot to know
Manoj Doubts
Awesome Answer. Liked it much
mahesh
There's also 'nm' for Unixes. 'objdump' is more powerful, but you need to understand the options.
quark
+8  A: 

The real starting point of the code is buried in the C runtime library. This runtime library calls your main() routine. In order for the linker to connect the C RTL call with your main() function, it needs to be visible outside the file.

External linkage is just this: it means that the name in question is visible as part of the exports of the object file. The job of the linker is to join up all of the imports and exports so that there are no outstanding imports.

Barry Kelly