linux extern关键字的作用

extern 的作用是起到一个链接作用！

 

    1.简单的例子。

 

     //包含头文件是为了声明这个函数,表示这个函数已经被定义过了，已经生产过二进制代码了。

#include <stdio.h>

int main(int argc, char **argv)
{
    printf("hello world!");
	return 0;
}

 

 

           

 

  假设现在是一个大工程，A.c include B.h  C.h，现在又有B.c  C.c文件。编译过程如何呢？

 

  编译是单个文件进行的。这句话如何理解呢？

 

   计算机最终执行的是二进制代码，我们用的库都是二进制机器码，CPU不停地吃，来执行指令。假设我们写好了许多

 

 许多好用的函数，从文本文件（main.c)编译成了二进制机器码文件(main.so，即库文件）。现在我需要利用这些基础的

 

函数形成重新组合调用，获得一些新的功能。比方说，我又添加了extra.c 来调用main.c中的函数。这时候就有了两种办法来生成新的二进制文件。

 

一种就是把main.c extra.c作为一个整体的whole.c来编译，生成whole.so二进制文件。从方法学的角度讲，这是整体

 

法。当然这是个不好的方法。聪明的办法分而治之，划分，化整体为局部。先把后来的extra.c编译好了之后，再整体化处

 

理，这个额外的过程就是链接。因为编译好的二进制代码是没必要重新生成的，只需要新的二进制代码执行后，跳入到编译

 

好的二进制代码那里执行就好了。

 

    又回到我们假设的工程，现在有三个文件，A.c, B.c, C.c，我们可以一个个编译成A.o, B.o, C.o，因为A调用了B，C,

 

所以最后的连接过程是不会丢失这个调用的关系的。链接的过程就像是声明一种边界一样。我在这里声明：这个是编译好的

 

文件，你不需要编译，你自己管你自己的就行了。最后连接器会把这个边界给缝合起来的。

 

 

  在例子中，我们看到，我们include 了<stdio.h>，这里声明了好多函数，就是告诉编译器，操作系统中这些函数都已经

 

实现了，（至于在哪里，我们最后再谈。），所以这个printf是合法的，然后我们用gcc -c file.c ，可以发现生成了file.o。

 

file.o 包含了printf的一个符号地址，用链接程序再替换一下，换成物理地址，gcc file.c -o file.exe，file.exe就包含

 

真正的物理地址了，就可以去call库文件中的函数了。这样程序就会执行了。

 

    同理，我们再试试这样写：

 

   extern int printf (__const char *__restrict __format, ...);

//printf这个函数是在库文件（libc.so.6 => /lib/tls/i686/cmov/libc.so.6）
//中已经被编译成了二进制代码
int main(int argc, char **argv)
{
    printf("hello world!");
	return 0;
}

 

   我们用gcc -c file.c可以看到命令是可以成功的。这里的extern也就是相当于#include <stdio.h>一样，告诉编译器一个

 

边界，这个，我是有二进制代码的！！（在某某二进制的库文件里面） 放过他，请继续编译。如果我们既没有头文件，也没

 

声明这个是个"已经编译好的二进制函数“（extern 可以看成是个 ”二进制函数“，我自己发明的，不正规）。编译一下如何？

 

结果是这个： 

 

    file.c:7: warning: incompatible implicit declaration of built-in function ‘printf’

 

编译会给个警告，自作聪明地给你反推出一个”二进制“函数，自己假设这个函数已经有了，然后连接搜索库，结果真找了，

 

呵呵。但是它的反推功能如何，我不知道。

 

    再假设，我们自己的函数，调用了一个sayhello(),结果sayhello()这个函数根本就没变成”二进制“函数，所以肯定会爆

 

一个函数没有的错误。

 

    看到这里，我们已经大概明白了编译的过程。这是一个万丈高楼平地起的过程，一个个函数被”二进制“化，一个个新的再

 

依赖这些”二进制函数“ 。库的过程就是这样，常用的所有基本功能编译好了，打成包，就成了库文件。新的开发依赖这个库

 

，所以我必须有这些库，而后，我自己再把自己的函数编译，打包，归档，形成了新的库，这样就形成了库的依赖关系。和

 

java的jar包是一个道理。

 

 从这里，我们也可以得出一个结论：头文件是开发的非必要条件。因为可以不include，直接手工声明，也是可以编译，

 

链接成功了。（头文件只是起到了一个方便的作用）。

 

如果你要用C++开发mysql, 如果有合适的库文件，不需要它的头文件，也是可以开发的呦，不过我没试，

 

所以不知道能不能成功，呵呵。注：（完整版的mysql，都是由开发包的，头文件，库文件一应俱全）。

 

最用我们用ldd明来看看都依赖了哪些库？

 

 

  bard@bard-desktop:~/sharing$ ldd file.exe

	linux-gate.so.1 =>  (0x002fe000)
	libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x00a5d000)
	/lib/ld-linux.so.2 (0x00c56000)
bard@bard-desktop:~/sharing$ 

 

最后，我们做一下拓展训练：

 

  首先只有一个文件：

 

int main(int argc, char **argv)
{
    sayHello();
	return 0;
}

 

 

    gcc -c file.c ，我们看到是不成功的。

 

 

    第二个文件

       #include <stdio.h>

int one=1;
int two=2;

void sayHello()
{
	printf("love you");
	
}

 

 

    gcc -c constant.c  是可以成功的，生成了constant.o（似乎sayHello函数已经二进制化了)

 

 

    但是这时gcc file.c -o file.exe，还是不成功，为什么呢？

 

 

    看来这个constant.o 和libc.so库文件是有区别的啊，如果我们把这个constant.o打包到libc.so中就可以了。呵呵

 

   正确做法是

 

   gcc constant.o file.c -o file.exe

 

   看来这个命令的含义是：  编译file.c 并和constant.o中的”二进制“函数sayHello进行链接。

 

   不知道，各位兄弟姐妹们是如何理解编译过程的，如果您有好的想法，请给我留言。