Linux编译器-gcc/g++的使用

Ⅰ 命令格式:

gcc [选项] 要编译的文件 [选项] [目标文件]

Ⅱ gcc编译原理:

①预处理(头文件展开，条件编译，宏替换，去注释):

对应选项:

-E作用是让gcc在预处理结束后停止编译过程;

-o xxx作用是让gcc在将产生的文件放到xxx中;

例如:生成预处理的文件，并且保存在hello.i中

gcc –E hello.c –o hello.i

②编译(C语言---->汇编语言)

对应选项:

-S从现在开始进行程序的翻译，当编译做完，就停下来。

例如:

gcc –S hello.i –o hello.s

③汇编(汇编语言---->可重定位目标文件，不可以被执行的，bin.obj)

只把我们自己的代码翻译成二进制文件

对应选项:

-c从现在开始进行程序的翻译，当汇编做完，就停下来。

例如:

gcc –c hello.s –o hello.o

④链接(将我们自己形成的.obj文件和库文件进行某种合并，形成可执行程序)

例如:

gcc hello.o –o hello

那么我们为什么能够在Linux下进行C，C++代码的编写和编译呢？

因为Linux系统默认已经携带了语言级别的头文件和语言对应的库;

在这里就涉及到一个重要的概念:

Ⅲ 函数库:

我们的C程序中，并没有定义“printf”的函数实现,且在预编译中包含的“stdio.h”中也只有该函数的声明,而没有定义函数的实现,那么,是在哪里实“printf”函数的呢?
最后的答案是:系统把这些函数实现都被做到名为 libc.so.6 的库文件中去了,在没有特别指定时,gcc 会到系统默认的搜索路径“/usr/lib”下进行查找,也就是链接到 libc.so.6 库函数中去,这样就能实现函数“printf”了,而这也就是链接的作用

Ⅲ. Ⅰ静态库:

静态库是指编译链接时,把库文件的代码**全部加入**到可执行文件中,因此生成的文件比较大,但在运行时也就不再需要库文件了。其后缀名一般为“.a”

例如:用静态库的方式生成可执行程序

gcc -static hello.o -o hellostatic

Ⅲ. Ⅱ 动态库:

动态库与静态库相反,在编译链接时并没有把库文件的代码加入到可执行文件中,而是在程序执行时由运行时链接文件加载库,这样可以节省系统的开销。动态库一般后缀名为“.so”,如前面所述的 libc.so.6 就是动态库。gcc 在编译时默认使用动态库。完成了链接之后,gcc 就可以生成可执行文件,如下所示 gcc hello.o –o hello
gcc默认生成的二进制程序，是动态链接的，这点可以通过 file 命令验证

Ⅳ gcc选项汇总:

-E 只激活预处理,这个不生成文件,你需要把它重定向到一个输出文件里面
-S 编译到汇编语言不进行汇编和链接
-c 编译到目标代码
-o 文件输出到文件
-static 此选项对生成的文件采用静态链接
-g 生成调试信息。GNU 调试器可利用该信息。
-shared 此选项将尽量使用动态库，所以生成文件比较小，但是需要系统由动态库.
-O0
-O1
-O2
-O3 编译器的优化选项的4个级别，-O0表示没有优化,-O1为缺省值，-O3优化级别最高
-w 不生成任何警告信息。
-Wall 生成所有警告信息

拓展：

①静态库和静态链接:链接的时候，如果是静态链接，进入静态库，拷贝静态库中我们需要的代码到我们的可执行程序中;

②动态库和动态链接:链接的时候，如果是动态链接，进入动态库，拷贝动态库中我们需要的地址到我们的可执行程序中的相关位置;

③静态链接成功:我们的程序，不依赖任何库，自己就可以独立运行。

④动态链接成功:我们的程序还是依赖于动态库，一旦动态库缺失，我们的程序便无法运行。

⑤静态库vs动态库:

静态库:因为自身拷贝的问题，比较浪费空间

动态库:因为可以做到被大家共享方法，所以真正所有的方法的实现永远都是放在库中，程序内部只有地址，比较节省空间。

Linux中默认使用的是动态链接和动态库！

Ⅳ Linux项目自动化构建工具-make/Makefile:

Ⅳ. Ⅰ背景：

会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力
一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作
makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。
make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。
make是一条命令，makefile是一个文件，两个搭配使用，完成项目自动化构建

Ⅳ. Ⅱ概念:

make 是一个命令;

makefile是一个文件;

Ⅳ. Ⅲ 规则:

makefile 是一个围绕依赖关系和依赖方法构建的一个自动化编译的工具;

完成一件事情，必须得有正确的依赖关系+正确的依赖方法;

Ⅳ. Ⅳ依赖关系:

hello.o , 它依赖 hello.s
hello.s , 它依赖 hello.i
hello.i , 它依赖 hello.c

Ⅳ. Ⅴ 依赖方法:

gcc hello.* -option hello.* 就是对应的依赖方法;

Ⅳ. Ⅵ 原理:

make是如何工作的,在默认的方式下，也就是我们只输入make命令。那么

make会在当前目录下找名字叫“Makefile”或“makefile”的文件。
如果找到，它会找文件中的第一个目标文件（target），在上面的例子中，他会找到“hello”这个文件，并把这个文件作为最终的目标文件。
如果hello文件不存在，或是hello所依赖的后面的hello.o文件的文件修改时间要比hello这个文件新（可以用 touch 测试），那么，他就会执行后面所定义的命令来生成hello这个文件。
如果hello所依赖的hello.o文件不存在，那么make会在当前文件中找目标为hello.o文件的依赖性，如果找到则再根据那一个规则生成hello.o文件。（这有点像一个堆栈的过程）
当然，你的C文件和H文件是存在的啦，于是make会生成 hello.o 文件，然后再用 hello.o 文件声明make的终极任务，也就是执行文件hello了。
这就是整个make的依赖性，make会一层又一层地去找文件的依赖关系，直到最终编译出第一个目标文件。
在找寻的过程中，如果出现错误，比如最后被依赖的文件找不到，那么make就会直接退出，并报错，而对于所定义的命令的错误，或是编译不成功，make根本不理。
make只管文件的依赖性，即，如果在我找了依赖关系之后，冒号后面的文件还是不在，那么对不起，我就不工作啦。

Ⅳ. Ⅶ 项目清理:

工程是需要被清理的
像clean这种，没有被第一个目标文件直接或间接关联，那么它后面所定义的命令将不会被自动执行，不过，我们可以显示要make执行。即命令——“make clean”，以此来清除所有的目标文件，以便重编译。
但是一般我们这种clean的目标文件，我们将它设置为伪目标,用 .PHONY 修饰,伪目标的特性是，总是被执行的。

实例:

#include <stdio.h>
int main()
{
	printf("hello Makefile!\n");
	return 0;
}

Makefile文件:

hello:hello.o  //依赖关系
gcc hello.o -o hello //依赖方法
hello.o:hello.s //依赖关系
gcc -c hello.s -o hello.o //依赖方法
hello.s:hello.i //依赖关系
gcc -S hello.i -o hello.s //依赖方法
hello.i:hello.c //依赖关系
gcc -E hello.c -o hello.i //依赖方法
.PHONY:clean  //.PHONNY：总是被执行！，之后的被称为伪目标
clean:
rm -f hello.i hello.s hello.o hello