把C程序的int main(void)改成static int main(void)会怎样呢？
如题，把C程序中的主函数int main(void)改成static int main(void)会怎么样呢？
比如把
#include <stdio.h>
int main(void)
{
printf("Hi\n");
return 0;
}
修改为：
#include <stdio.h>
static int main(void)
{
printf("Hi\n");
return 0;
}
请读者先自己想一想！
————————————————————分割线———————————————————
这个问题是我在看static关键字的时候提出来的。
只要你了解static关键字会使标示符具有内部链接（Internel Linkage）属性，并且了解过C程序的编译链接流程，应该可以得出答案——
把C程序中的主函数int main(void)改成static int main(void)会导致链接失败。
可以验证一下：
[zhanghaiba@Fedora code]$ gcc static_int_main.c
/usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
如果换成gcc -c呢？
[zhanghaiba@Fedora code]$ gcc -c static_int_main.c
[zhanghaiba@Fedora code]$
可见换成gcc -c可以编译成功，因为gcc -c只有预处理、编译和汇编阶段，没有链接阶段。
首先，我们要了解一下Linux下GCC环境中C程序的编译链接流程——
编译C程序，一般包括了C预处理阶段、C到汇编的编译阶段、汇编到目标文件的编译阶段、目标文件的链接阶段。
GCC支持下面几个命令，使我们可以观察到这些阶段：
1）gcc -v GCC.c
编译时打印出总的编译流程，可以看到使用了哪些编译工具。v是verbose（冗长）的意思，即尽可能多的打印信息。
2) gcc -E GCC.c
把源文件用预处理器处理，可重定向输出到GCC.i文件再查看
3）gcc -S GCC.c
把源文件用预处理器和编译器处理，自动输出同名的GCC.s文件
4）gcc -c GCC.c
把源文件用预处理器、编译器和汇编器处理，自动输出同名.o文件
5）gcc GCC.c
把源文件用预处理器、编译器、汇编器处理后，最后使用链接器生成缺省名为a.out的可执行文件
为什么默认叫a.out？因为早期编译并没有链接器的概念，a.out是汇编器直接生成的，a意为assembly。但需要澄清的是在现代编译器中a.out都是由链接器生成。
另外，使用选项-save-temps可以保留中间生成的文件，示范如下：
[zhanghaiba@Fedora code]$ ls | grep hi
hi.c
hi.i
hi.o
hi.s
我们再用gcc -v来观察总的编译流程
[zhanghaiba@Fedora code]$ gcc -v hi.c
Using built-in specs.
Target: i686-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch=i686 --build=i686-redhat-linux
Thread model: posix
gcc version 4.4.5 20101112 (Red Hat 4.4.5-2) (GCC)
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-redhat-linux/4.4.5/cc1 -quiet -v hi.c -quiet -dumpbase hi.c -mtune=generic -march=i686 -auxbase hi -version -o /tmp/ccrwAICf.s
ignoring nonexistent directory "/usr/lib/gcc/i686-redhat-linux/4.4.5/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/i686-redhat-linux/4.4.5/../../../../i686-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-redhat-linux/4.4.5/include
/usr/include
End of search list.
GNU C (GCC) version 4.4.5 20101112 (Red Hat 4.4.5-2) (i686-redhat-linux)
compiled by GNU C version 4.4.5 20101112 (Red Hat 4.4.5-2), GMP version 4.3.1, MPFR version 2.4.2.
GGC heuristics: --param ggc-min-expand=81 --param ggc-min-heapsize=95788
Compiler executable checksum: e892644090a9a7e8c330a388c51818dd
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
as -V -Qy -o /tmp/cc1w7Hxi.o /tmp/ccrwAICf.s
GNU assembler version 2.20.51.0.2 (i686-redhat-linux) using BFD version version 2.20.51.0.2-15.fc13 20091009
COMPILER_PATH=/usr/libexec/gcc/i686-redhat-linux/4.4.5/:/usr/libexec/gcc/i686-redhat-linux/4.4.5/:/usr/libexec/gcc/i686-redhat-linux/:/usr/lib/gcc/i686-redhat-linux/4.4.5/:/usr/lib/gcc/i686-redhat-linux/:/usr/libexec/gcc/i686-redhat-linux/4.4.5/:/usr/libexec/gcc/i686-redhat-linux/:/usr/lib/gcc/i686-redhat-linux/4.4.5/:/usr/lib/gcc/i686-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/i686-redhat-linux/4.4.5/:/usr/lib/gcc/i686-redhat-linux/4.4.5/:/usr/lib/gcc/i686-redhat-linux/4.4.5/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
/usr/libexec/gcc/i686-redhat-linux/4.4.5/collect2 --no-add-needed --eh-frame-hdr --build-id -m elf_i386 --hash-style=gnu -dynamic-linker /lib/ld-linux.so.2 /usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crt1.o /usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crti.o /usr/lib/gcc/i686-redhat-linux/4.4.5/crtbegin.o -L/usr/lib/gcc/i686-redhat-linux/4.4.5 -L/usr/lib/gcc/i686-redhat-linux/4.4.5 -L/usr/lib/gcc/i686-redhat-linux/4.4.5/../../.. /tmp/cc1w7Hxi.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i686-redhat-linux/4.4.5/crtend.o /usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crtn.o
注意红色加粗部分（由绿色文件生成红色文件）——
（1）cc1是GCC编译环境中的C编译器，把C代码编译为汇编代码，输出为.s文件
（2）as是汇编器，把汇编代码编译为目标文件，输出为.o文件
（3）collect2是GCC后期版本使用的链接器（环境），其实是先调用GNU的链接器ld对目标文件进行链接，最后收集与程序初始化相关的信息，构造程序的初始化结构。
ld是真正的链接器，对上一步的.o目标文件和其它需要.o文件或静态链接库.a文件、动态链接库.so文件（如解压C标准库libc.a中取出需要的printf.o文件），一起链接输出为a.out文件。
GCC后期版本使用了collect2来作为链接器，其实是间接调用ld链接器。
上面用到的工具中，as是GNU自带的汇编器，ld是GNU自带的链接器，它俩是GNU Binutils中最主要的二进制工具。
其中，ld-linux.so.2是动态链接器。最后注意-lc参数，l表示链接，c表示标准C库，即libc.a或libc.so。
让我们回到问题本身——
main不是C语言的关键字，但却是约定俗成的主函数名字，不过它并不是程序执行的入口，
C程序真正入口是_start全局符号（由汇编实现的函数），_start函数会调用库函数__libc_start_main，然后__libc_start_main再调用main函数
我们知道main函数的声明无非两种形式，main函数的声明（main符号）其实是在crt1.o目标文件中
通过nm工具可以查看crt1.o包括了哪些符号
[zhanghaiba@Fedora code]$ nm /usr/lib/crt1.o 00000000 R _IO_stdin_used 00000004 D __data_start U __libc_csu_fini U __libc_csu_init U __libc_start_main 00000044 R _fp_hw 00000020 T _start 00000004 W data_start U main
crt1.o中已经有了main符号，但却是未定义(U)的，所以需要我们来实现main函数（即定义main符号），最后通过链接器来链接（这里称作符号解析）
如果把main函数定义为static，也就是具有内部链接(Internel Linkage)属性，则编译后的目标文件是局部符号（当前文件可见）
然而链接是不会对局部符号做符号解析的，只会根据目标文件的.rel.text段来指示链接全局的且未定义的符号（即修改可重定位目标文件REL的符号地址）
因此，链接时main符号找不到定义，这导致main符号找不到具体实现（定义），造成链接失败
我们再看编译失败的反馈信息
/usr/lib/gcc/i686-redhat-linux/4.4.5/../../../crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: ld returned 1 exit status
就不难理解了——
在函数_start中，引用了未定义的符号main
collect2外壳：链接器ld返回1标记退出状态（出错状态）
@Author: 张海拔
@Update: 2014-2-10
@Link: http://www.cnblogs.com/zhanghaiba/p/3545132.html
