gcc编译程序。
第一种，最简单的情况，单源码编译
1、
假如我们写了一个名为hello.c的C语言程序(其实也就是名为hello.c的纯文本)：
//hello.c
#include <stdio.h>
int main(void)
{
printf("Hello World\n");
}这个程序就是所谓的源代码。也就是程序员编写出来的程序。
此时这个程序是不能够直接运行的，因为它只是个纯文本。能够运行的是可执行程序。文件夹中是这样的：
第一种情况，最简单的，直接用gcc：
//直接用gcc指令将编译链接过程一步走过。
gcc hello.c执行完后，文件夹是这样的：
//上步执行完后，会在同位置目录里生成一个a.out文件。然后运行就可以了。
./a.out
Hello World第二种情况，编译链接分开，并设定输出的可执行文件名：
#编译，这步就是将hello.c文件编译成机器码。这步过后会生成hello.o文件，这个就是编译后的文件，叫目标文件！
gcc -c hello.c第一步过后文件夹里多了个hello.o(hello.c的类型为文字，就是字符。而hello.o的类型已经变成了文档，就是二进制了)：
#链接，这步就是将上步生成的目标文件链接生成可执行文件，同时还能命名可执行文件。这步过后，会生成你自己命名的可执行文件。
gcc -o hello hello.o第二步过后，就生成了我们定义的hello可执行文件(齿轮图标文件，类型为程序)：
#最后就会有生成的名为hello的可执行文件，运行就可以了。跟上方一样的输出结果
./hello
Hello World整个分开的过程可以发现，后一步都是用的前一步生成的文件去操作，也就是gcc -o 的时候，用的是上一步生成的hello.o，跟最初的hello,c 其实没有什么关系了。
第二种，需要链接的多源码编译
上面的情况编译时只有hello.c一个源代码，加入要是有好多个源代码呢？
首先我们有两个源代码，
一个是thanks.c：
//thanks.c
#include <stdio.h>
int main(void)
{
printf("Hello World\n");
thanks_2();
}发现它调用了thanks_2()函数。这个函数在另外一个源代码thanks_2中:
//thanks_2.c
#include <stdio.h>
void thanks_2(void)
{
printf("Thank you!\n");
}这种情况很符合实际使用，因为thanks_2这种专业函数，可能是你花钱购买的特殊需求的函数，而你在thanks中只管调用就可以了。不用管它怎么实现的。
当然编译也很简单，摞在一起就好了：
//编译，会生成thanks.o和thanks_2.o
gcc -c thanks.c thanks_2.c
//链接，会生成thanks可执行文件
gcc -o thanks thanks.o thanks_2.o
//运行，输出。
./thanks
Hello World
Thank you!上方是最直接的编译链接方式，直接利用gcc编译器进行手动操作，其实一般使用是基本都是用Cmake来操作的。关于Cmake，后面再说。
考虑到管理用户所安装软件的便利性。通常我们会建议大家将自己安装的软件放置在 /usr/local 下,源代码则建议放置在 /usr/local/src (src 为 source 的缩写)底下。
Linux distribution 默认的安装软件的路径会用到哪些?
- /etc/httpd
- /usr/lib
- /usr/bin
- /usr/share/man
会发现软件的内容大致上是分布在 etc, lib, bin, man 等目录当中,分别代表『配置文件、函数库、可执行文件、联机帮助文档』。
也就是说，安装完一个软件后，跟它相关的各个部分根据功能的不同散落在归类的各个文件加中。在lib、bin当中都会有软件名称的文件夹。而不是Windows当中的一个程序就一个文件夹，都放在里面！！
动态与静态函数库
静态函式库的特色:
- 扩展名:(扩展名为 .a)
这类的函数库通常扩展名为 libxxx.a 的类型 - 编译行为:
这类函数库在编译的时候会直接整合到执行程序当中,所以利用静态函数库编译成的文件会比较大一些; - 独立执行的状态:
这类函数库最大的优点,就是编译成功的可执行文件可以独立执行,而不需要再向外部要求读取函数库的内容 (请参照动态函数库的说明)。 - 升级难易度:
虽然执行文件可以独立执行,但因为函数库是直接整合到可执行文件中, 因此若函数库升级时,整个可执行文件必须要重新编译才能将新版的函数库整合到程序当中。也就是说,在升级方面,只要函数库升级了,所有将此函数库纳入的程序都需要重新编译!
动态函式库的特色:
- 扩展名:(扩展名为 .so)
这类函式库通常扩展名为 libxxx.so 的类型; - 编译行为:
动态函式库与静态函式库的编译行为差异挺大的。与静态函式库被整个捉到程序中不同的,动态函式库在编译的时候,在程序里面只有一个『指向(Pointer)』的位置而已。也就是说,动态函式库的内容并没有被整合到执行档当中,而是当执行档要使用到函式库的机制时,程序才会去读取函式库来使用。由于执行文件当中仅具有指向动态函式库所在的指标而已, 并不包含函式库的内容,所以他的文件会比较小一点。 - 独立执行的状态:
这类型的函式库所编译出来的程序不能被独立执行, 因为当我们使用到函式库的机制时,程序才会去读取函式库,所以函式库文件『必须要存在』才行,而且,函式库的『所在目录也不能改变』,因为我们的可执行文件里面仅有『指标』亦即当要取用该动态函式库时,程序会主动去某个路径下读取,呵呵!所以动态 函式库可不能随意移动或删除,会影响很多相依的程序软件喔! - 升级难易度:
虽然这类型的执行档无法独立运作,然而由于是具有指向的功能, 所以,当函式库升级后,执行档根本不需要进行重新编译的行为,因为执行档会直接指向新的函式库文件 (前提是函式库新旧版本的档名相同! )。
目前的 Linux distribution 比较倾向于使用动态函式库,因为如同上面提到的最重要的一点, 就是函式库的升级方便!由于 Linux 系统里面的软件相依性太复杂了,如果使用太多的静态函式库,那么升级某一个函式库时, 都会对整个系统造成很大的冲击!因为其他依赖项也要同时重新编译啊! 这个时候动态函式库可就有用多了,因为只要动态函式库升级就好,其他的软件根本无须变动。
那么这些函式库放置在哪里呢?绝大多数的函式库都放置在:/lib64, /lib 目录下!
源码的安装形式，确实比较烦。如果我的 Linux 系统与厂商的系统一模一样,那么在厂商的系统上面编译出来的可执行文件, 自然也就可以在我的系统上面跑!
也就是说,厂商先在他们的系统上面编译好了我们用户所需要的软件, 然后将这个编译好的可执行的软件直接释出给用户来安装,如此一来,由于我们本来就使用厂商的 Linux distribution ,所以当然系统 (硬件与操作系统) 是一样的,那么使用厂商提供的编译过的可执行文件就没有问题!
说简单点就是利用类似 Windows 的安装方式,由程序开发者直接在已知的系统上面编译好,再将该程序直接给用户来安装。
那么如果在安装的时候还可以加上一些与这些程序相关的信息,将他建立成为数据库,那不就可以进行安装、反安装、 升级与验证等等的相关功能了么 (类似 Windows 底下的『新增移除程序』)?确实如此,在 Linux 上有两种常见的这方面的软件管理方式,分别是 RPM 与 Debian 的 dpkg 。
目前在 Linux 界软件安装方式最常见的有两种,分别是:
- dpkg:
这个机制最早是由 Debian Linux 社群所开发出来的,透过 dpkg 的机制, Debian 提供的软件就能够简单的安装,同时还能提供安装后的软件信息。只要是衍生于 Debian 的其他 Linux distributions大多使用 dpkg 机制来管理软件, 包括 B2D, Ubuntu 等等。 - RPM:
这个机制最早是由 Red Hat 这家公司开发出来,后来实在很好用,因此很多 distributions 就使用这个机制来作为软件安装的管理方式。包括 Fedora, CentOS, SuSE 等等知名的开发商都使用。
如前所述,不论 dpkg/rpm 这些机制或多或少都会有软件依赖项的问题, 回想前面谈到过的每个软件文件都会提供相依属性的检查。那么如果我们将相依属性的数据做成列表, 等到实际软件安装时,若有依赖项时,例如安装 A 需要先安装 B 与 C ,
而安装 B 则需要安装 D 与 E 时,那么当你要安装 A ,透过相依属性列表,管理机制自动去取得B, C, D, E 来同时安装, 不就解决了属性相依的问题吗?
没错!目前新的 Linux 开发商都有提供这样的『在线升级』机制,透过这个机制, 原版光盘就只有第一次安装时需要用到而已,其他时候只要有网络,你就能够取得原本开发商所提供的任
何软件!
在dpkg 管理机制上就开发出 APT 的在线升级机制,RPM 则依开发商的不同,有Red Hat 系统的 yum , SuSE 系统的 Yast Online Update (YOU) 等。
来张表：
书中并没有介绍apt的用法，而是介绍的RPM。后面再写apt吧。。。