【Linux修炼】6.gcc/g++及Makefile【工具篇】

每一个不曾起舞的日子，都是对生命的辜负。

Linux-gcc/g++及Makefile

本节目标

1. 了解gcc/g++的使用
2. 掌握makefile的原理
3. 进度条

程序的翻译过程

在C语言中，我们已经学过程序的编译和链接，在这里将复习一下我们之前所学的内容并引出后续gcc/g++的内容。

1.程序的翻译过程

预处理（头文件展开，去注释，宏替换，条件编译）
编译：把C变成汇编语言
汇编：把汇编变成二进制（不是可执行，二进制目标文件不能被执行）
链接：把你下的代码和C标准库中的代码合起来

2. 理解选项的含义

如果我们直接gcc test.c 就会跳过上述四个过程直接编译生成最终的a.out可执行文件，因此我们不直接这样，而是划分成四条指令依次执行上述的四步翻译过程，在此过程中理解选项的含义。

3. 动态链接和静态链接

首先我们要清楚，我们自己写的代码和库是两码事。C标准库是别人给我们准备好的，让我们直接使用的。我们所有使用库中函数的代码（printf()），其中我们自己只写了该函数的调用，没有对应的实现！只有当链接的时候，对应的实现才和我们的代码关联起来！

那么这就引入了链接，链接的本质：无非就是我们调用库函数的时候和标准库如何关联的问题。这种关联就包括动态和静态。

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

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

gcc默认生成的二进制程序，是动态链接的，这点可以通过 file 命令验证。

事实上，对于动态和静态的理解，就好比在网吧还是家上网一样。如果你在网吧，此时网吧升级就会影响到你，这也就是所谓的动态；如果把网吧的电脑买来带回家上网，说明你已经有一台自己的电脑，相当于拷贝了一份网吧的电脑到自己家，上网就不会受到网吧升级时的影响，这就是所谓的静态。

因此经过定义与理解的总结：

动态链接： 受库升级或者被删除的影响，形成的可执行程序小，节省资源。
静态链接： 不受库升级或者被删除的影响，形成的可执行程序提交太大！ – 网络，磁盘，内存

在Linux下库的命名：

动态库：lib XXXXXXX.so
静态库：lib XXXXXXX.a

即去掉前缀lib和相应的后缀，就是库的名字。举例：libc.so.6就是c标准库。

当我们执行查看c标准库的时候，就可以看到具体的信息，并发现此标准库默认是.so结尾的动态库。

对于动态库和静态库来说，动态库是系统自带的，即系统安装完毕就可以使用，而静态库则一般需要我们自己安装，这也说明了静态库并不是直接拷贝动态库的内容。因此我们需要手动安装一下静态库：
sudo yum install -y glibc-static

安装静态库定之后，我们就可以通过在已有的指令基础上加上

-static

指定静态库编译：

即系统本身，为了支持我们编程，给我们提供了标准库.h（告诉我们怎么用:标准的动静态库.so/.a）而对于此动静态链接，我们是基于Linux系统去演示的，事实上也只对Linux环境有效，但对于windows来说，其原理是一样的（windows下的动态库：.dll 静态库：.lib)

安装C++版本的gcc(g++)：

sudo yum install -y gcc-g++

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

1. 背景

会不会写makefile，从一个侧面说明了一个人是否具备完成大型工程的能力

一个工程中的源文件不计数，其按类型、功能、模块分别放在若干个目录中，makefile定义了一系列的规则来指定，哪些文件需要先编译，哪些文件需要后编译，哪些文件需要重新编译，甚至于进行更复杂的功能操作

makefile带来的好处就是——“自动化编译”，一旦写好，只需要一个make命令，整个工程完全自动编译，极大的提高了软件开发的效率。

make是一个命令工具，是一个解释makefile中指令的命令工具，一般来说，大多数的IDE都有这个命令，比如：Delphi的make，Visual C++的nmake，Linux下GNU的make。可见，makefile都成为了一种在工程方面的编译方法。

make是一条命令，makefile是一个文件，两个搭配使用，完成项目自动化构建。

2. “见见猪跑”

对于makefile，若想利用make命令，则必须创建makefile命名的文件（m大写也可），在内部编写一定的依赖规则之后，我们通过make就可以对应的执行程序，就省略了类似于这种

gcc test.c -o test

的编译指令，好我们来看看如何操作：

步骤1： 创建makefile文件，并在makefile文件里编辑相应的依赖关系和依赖方法

步骤2：执行make指令并输出

这样最大的效果就是不用再写gcc编译了。

3. makefile原理及语法

3.1 Makefile原理

探讨makefile的原理，其最核心的内容就是依赖关系和依赖方法

那么什么是所谓的依赖关系和依赖方法呢？对于上面的步骤来说，在makefile文件中：第一行代表着依赖关系，也就是mycode这个要生成的文件是基于mycode.c实现的，mycode依赖于mycode.c。但仅仅有了依赖关系是不够的，需要明白这种关系是为了什么或者是继续什么原因才依赖的，也就是所谓的依赖方法，在第二行中，我们看到mycode是基于mycode.c经过gcc编译生成的，即gcc就是依赖方法。

3.2 Makefile语法

就此例来说，第一行仍是依赖关系，但注意下面必须是tab造成的空格，而不是直接按四下空格。

此外，对于新增的clean来说，也是有一定意义的，

.PHONY

：被改关键字修饰的对象是一个伪目标。我们知道在make时会生成mycode，通过clean这样的方式，就可以将其用make clean 删除：

对于

.PHONY

来说：这个伪目标总是被执行的。那么如何理解这句话呢？

我们先来看看这样的演示：

我们发现，当这个mycode已经是最新版本的情况·下，是不会再次gcc出来的。

那如果我们将makefile进行如下的修改：

修改后：

发现其仍然是可以执行的。这就是所谓的伪目标总是被执行的含义。

注：对于第一条指令来说，默认规定直接make就可以执行，就比如上面的gcc，这与make clean一样的完整写法make mycode来说是一样的。

4. gcc不更新文件的剖析

对于上面的示例，我们知道了gcc对于已经是最新版本的生成的执行文件来说并不会将其改变，并会提示已经是最新版本，就上面的mycode.c来说，是mycode.c的modify时间不如mycode的modify时间晚，即是在最新的mycode.c下生成的mycode是不会被gcc再次编译生成的，这是由于mycode是基于mycode.c所创建出来的。

因此对于上面的

.PHONY

的gcc来说，其能执行是因为

.PHONY

规定之后，就不遵循这个所谓时间的规则。

5. 理解makefile的推导规则

为了演示推导过程，我们将makefile中的依赖关系进行拆分（但最终效果是一样的）

通过以上修改，我们退出vim模式并执行make

我们发现，对于makefile的依赖关系来说，是从上到下的，即mycode依赖于mycode.o，但此时并没有mycode.o，因此就需要找mycode.o的依赖对象mycode.s，mycode.s继续找他的依赖对象mycode.i，但mycode.i也并不存在，mycode.i就会找他的依赖对象mycode.c，mycode.c是存在的，因此执行情况是从下到上的。

但对于此推导规则，我们只需要明白其中的逻辑，真正利用makefile的时候，没必要将原来的一条gcc指令变成好几条指令。