20220927 21. 软件安装：源代码与 Tarball

20.1 开放源码的软件安装与升级简介

21.1.1 什么是开放源码、编译器与可可执行文件

• 开放源码：就是程序码，写给人类看的程序语言，但机器并不认识，所以无法执行；

• 编译器：将程序码转译成为机器看的懂得语言，就类似翻译者的角色；

• 可可执行文件：经过编译器变成二进制程序后，机器看的懂所以可以执行的文件。

[root@VM-72-146-centos ~]# file /bin/bash
/bin/bash: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=d9676f0171683e13b82c79377d8a3657be5ff6e1, stripped
[root@VM-72-146-centos ~]# file /etc/init.d/network 
/etc/init.d/network: Bourne-Again shell script, ASCII text executable

如果是 binary 而且是可以执行的时候，他就会显示可执行文件类别 （ELF 64-bit LSB executable）， 同时会说明是否使用动态函数库 （shared libs），而如果是一般的 script ，那他就会显示出 text executables 之类的字样！

在 Linux 上面最标准的程序语言为 C ，写完之后，以 Linux 上标准的 C 语言编译器 gcc 这支程序来编译，就可以制作一支 可以执行的 binary program 啰。

20.1.2 什么是函数库

函数库：就类似副程序的角色，可以被调用来执行的一段功能函数。

Linux 的核心提供很多 的核心相关函数库与外部参数， 这些核心功能在设计硬件的驱动程序的时候是相当有用的信 息，这些核心相关信息大多放置在 /usr/include, /usr/lib, /usr/lib64 里面哩！

程序执行时引用外部动态函数库

20.1.3 什么是 make 与 configure

当执行 make 时，make 会在当时的目录下搜寻 Makefile （or makefile） 这个文本文件，而 Makefile 里面则记录了源代码如何编译的详细信息！

那 Makefile 怎么写？ 通常软件开发商都会写一支 侦测程序来侦测使用者的作业环境， 以及该作业环境是否有软件开发商所需要的其他功能， 该侦测程序侦测完毕后，就会主动的创建这个 Makefile 的规则文件啦！通常这支侦测程序的 文件名为 configure 或者是 config 。

为什么要侦测作业环境呢？不是曾经提过其实每个 Linux distribution 都使用同样的核心吗？但你得要注意， 不同版本的核心所使用的系统调用可能不相同，而且 每个软件所需要的相依的函数库也不相同， 同时，软件开发商不会仅针对 Linux 开发，而是会针对整个 Unix-Like 做开发啊！ 所以他也必须要侦测该操作系统平台有没有提供合适的编 译器才行！所以当然要侦测环境啊！ 一般来说，侦测程序会侦测的数据大约有下面这些：

• 是否有适合的编译器可以编译本软件的程序码；

• 是否已经存在本软件所需要的函数库，或其他需要的相依软件；

• 操作系统平台是否适合本软件，包括 Linux 的核心版本；

• 核心的表头定义文件 （header include） 是否存在 （驱动程序必须要的侦测）。

因 为调用的目标函数库位置可能不同 ， 核心版本更不可能相同！所以同一套软件要在不同的平台上面执行时， 必须要重复编译！所以 才需要源代码嘛！

20.1.4 什么是 Tarball 的软件

所谓的 Tarball 文件，其实就是将软件的所有源代码文件先以 tar 打包，然后再以压缩技术来 压缩

Tarball 是一个软件包， 你将他解压缩之后，里面的文件 通常就会有：

• 原始程序码文件；

• 侦测程序文件 （可能是 configure 或 config 等文件名）；

• 本软件的简易说明与安装说明 （INSTALL 或 README）

20.1.5 如何安装与升级软件

基本上更新的方法可以分为两大类，分别是：

• 直接以源代码通过编译来安装与升级；

• 直接以编译好的 binary program 来安装与升级。

预先编译好程序的机制存在于很多 distribution 喔，包括有 Red Hat 系统 （含 Fedora/CentOS 系列） 发展的 RPM 软件管理机制与 yum 线上更新模式； Debian 使用的 dpkg 软件管理机制与 APT 线上更新模式等等。

由于 CentOS 系统是依循标准的 Linux distribution，所以可以使用 Tarball 直接进行编译的安 装与升级， 当然也可以使用 RPM 相关的机制来进行安装与升级

一个软件的 Tarball 是如何安装的呢？基本流程是这样的啦：

1. 将 Tarball 由厂商的网页下载下来；

2. 将 Tarball 解开，产生很多的源代码文件；

3. 开始以 gcc 进行源代码的编译 （会产生目标文件 object files）；

4. 然后以 gcc 进行函数库、主、副程序的链接，以形成主要的 binary file；

5. 将上述的 binary file 以及相关的配置文件安装至自己的主机上面。

第 3, 4 步骤当中，我们可以通过 make 这个指令的功能来简化他

21.2 使用传统程序语言进行编译的简单范例

21.2.1 单一程序：印出 Hello World

[root@www ~]# vim hello.c   <==用 C 语言写的程序扩展名建议用 .c
#include <stdio.h>
int main(void)
{
        printf("Hello World\n");
}

gcc hello.c    # 生成 a.out 可执行文件
./a.out            # 执行

gcc -c hello.c
gcc -o hello hello.o
./hello            # 执行

21.2.2 主、副程序链接：副程序的编译

# 1. 编辑主程序：
[root@www ~]# vim thanks.c
#include <stdio.h>
int main(void)
{
        printf("Hello World\n");
        thanks_2();
}
# 上面的 thanks_2(); 那一行就是呼叫副程序啦！

[root@www ~]# vim thanks_2.c
#include <stdio.h>
void thanks_2(void)
{
        printf("Thank you!\n");
}

# 2. 开始将原始码编译成为可运行的 binary file ：
[root@www ~]# gcc -c thanks.c thanks_2.c
[root@www ~]# ll thanks*
-rw-r--r-- 1 root root  76 Jun  5 16:13 thanks_2.c
-rw-r--r-- 1 root root 856 Jun  5 16:13 thanks_2.o  <==编译产生的！
-rw-r--r-- 1 root root  92 Jun  5 16:11 thanks.c
-rw-r--r-- 1 root root 908 Jun  5 16:13 thanks.o    <==编译产生的！
[root@www ~]# gcc -o thanks thanks.o thanks_2.o
[root@www ~]# ll thanks*
-rwxr-xr-x 1 root root 4870 Jun  5 16:17 thanks     <==最终结果会产生这玩意儿

# 3. 运行一下这个文件：
[root@www ~]# ./thanks
Hello World
Thank you!

[root@www ~]# gcc -O -c thanks.c thanks_2.c  <== -O 为产生最佳化的参数

[root@www ~]# gcc -Wall -c thanks.c thanks_2.c
thanks.c: In function 'main':
thanks.c:5: warning: implicit declaration of function 'thanks_2'
thanks.c:6: warning: control reaches end of non-void function
# -Wall 为产生更详细的编译过程资讯。上面的信息为警告信息 (warning)
# 所以不用理会也没有关系！

21.2.3 调用外部函数库：加入链接的函数库

略

21.2.4 gcc 的简易用法 （编译、参数与链结）

略

21.3 用 make 进行宏编译

21.3.1 为什么要用 make

make 有这些好处：

• 简化编译时所需要下达的指令；

• 若在编译完成之后，修改了某个源代码文件，则 make 仅会针对被修改了的文件进行编译，其他的 object file 不会被更动；

• 最后可以依照相依性来更新 （update） 可执行文件。

21.3.2 makefile 的基本语法与变量

略

21.4 Tarball 的管理与建议

21.4.1 使用源代码管理软件所需要的基础软件

• gcc 或 cc 等 C 语言编译器 （compiler）：

• make 及 autoconfig 等软件：

• 需要 Kernel 提供的 Library 以及相关的 Include 文件：

通过 yum 的软件群组安装功能，你可以这样做：

• 如果是要安装 gcc 等软件发展工具，请使用“ yum groupinstall “Development Tools” ”

• 若待安装的软件需要图形接口支持，一般还需要“ yum groupinstall “X Software Development” ”

• 若安装的软件较旧，可能需要“ yum groupinstall “Legacy Software Development” ”

21.4.2 Tarball 安装的基本步骤

整个 安装的基础动作大多是这样的：

1. 取得原始文件：将 tarball 文件在 /usr/local/src 目录下解压缩；

2. 取得步骤流程：进入新创建的目录下面，去查阅 INSTALL 与 README 等相关文件内容（很重要的步骤！）；

3. 相依属性软件安装：根据 INSTALL/README 的内容察看并安装好一些相依的软件 （非必要）；

4. 创建 makefile：以自动侦测程序 （configure 或 config） 侦测作业环境，并创建 Makefile 这个文件；

5. 编译：以 make 这个程序并使用该目录下的 Makefile 做为他的参数配置文件，来进行make （编译或其他） 的动作；

6. 安装：以 make 这个程序，并以 Makefile 这个参数配置文件，依据 install 这个标的 （ arget） 的指定来安装到正确的路径！

大部分的 tarball 软件之安装的指令下达方式：

1. ./configure ：这个步骤就是在创建 Makefile 这个文件啰！通常程序开发者会写一支 scripts 来检查你的 Linux 系统、相关的软件属性等等，这个步骤相当的重要， 因为未来你的安 装信息都是这一步骤内完成的！另外，这个步骤的相关信息应该要参考一下该目录下的 README 或 INSTALL 相关的文件！

2. make clean ：make 会读取 Makefile 中关于 clean 的工作。这个步骤不一定会有，但是希 望执行一下，因为他可以去除目标文件！因为谁也不确定源代码里面到底有没有包含上 次编译过的目标文件 （*.o） 存在，所以当然还是清除一下比较妥当的。 至少等一下新 编译出来的可执行文件我们可以确定是使用自己的机器所编译完成的嘛！

3. make ：make 会依据 Makefile 当中的默认工作进行编译的行为！编译的工作主要是进行 gcc 来将源代码编译成为可以被执行的 object files ，但是这些 object files 通常还需要一 些函数库之类的 link 后，才能产生一个完整的可执行文件！使用 make 就是要将源代码 编译成为可以被执行的可可执行文件，而这个可可执行文件会放置在目前所在的目录之 下， 尚未被安装到预定安装的目录中；

4. make install ：通常这就是最后的安装步骤了，make 会依据 Makefile 这个文件里面关于 install 的项目，将上一个步骤所编译完成的数据给他安装到预定的目录中，就完成安装 啦！

上面的步骤是一步一步来进行的，而其中只要一个步骤无法成功，那么后续的步骤 就完全没有办法进行的

如果安装 成功， 并且是安装在独立的一个目录中，例如 /usr/local/packages 这个目录中好了，那么你 就必需手动的将这个软件的 man page 给他写入 /etc/man_db.conf 里面去。

21.4.3 一般 Tarball 软件安装的建议事项 （如何移除？升级？）

建议使用 者：

1. 最好将 tarball 的原始数据解压缩到 /usr/local/src 当中；

2. 安装时，最好安装到 /usr/local 这个默认路径下；

3. 考虑未来的反安装步骤，最好可以将每个软件单独的安装在 /usr/local 下面；

4. 为安装到单独目录的软件之 man page 加入 man path 搜寻： 如果你安装的软件放置到 /usr/local/software/ ，那么 man page 搜寻的设置中，可能就得要在 /etc/man_db.conf 内 的 40~50 行左右处，写入如下的一行：

    MANPATH_MAP /usr/local/software/bin /usr/local/software/man
   

时至今日，老实说，真的不太需要有 tarball 的安装了！CentOS/Fedora 有个 RPM 补遗 计划，就是俗称的 EPEL 计划，相关网址说明如下： https://fedoraproject.org/wiki/EPEL

一 般学界会用到的软件都在里头

21.4.4 一个简单的范例、利用 ntp 来示范

略

21.4.5 利用 patch 更新源代码

略

21.5 函数库管理

21.5.1 动态与静态函数库

依据函数库被使用的类型而分为两大类，分别 是静态 （Static） 与动态 （Dynamic） 函数库两类

静态函数库的特色：

• 扩展名：（扩展名为 .a） 这类的函数库通常扩展名为 libxxx.a 的类型；

• 编译行为： 这类函数库在编译的时候会直接整合到执行程序当中，所以利用静态函数库 编译成的文件会比较大一些喔；

• 独立执行的状态： 这类函数库最大的优点，就是编译成功的可可执行文件可以独立执 行，而不需要再向外部要求读取函数库的内容 （请参照动态函数库的说明）。

• 升级难易度： 虽然可执行文件可以独立执行，但因为函数库是直接整合到可执行文件 中， 因此若函数库升级时，整个可执行文件必须要重新编译才能将新版的函数库整合到 程序当中。 也就是说，在升级方面，只要函数库升级了，所有将此函数库纳入的程序都 需要重新编译！

动态函数库的特色：

• 扩展名：（扩展名为 .so） 这类函数库通常扩展名为 libxxx.so 的类型；

• 编译行为： 动态函数库与静态函数库的编译行为差异挺大的。 与静态函数库被整个捉到 程序中不同的，动态函数库在编译的时候，在程序里面只有一个“指向 （Pointer）”的位 置而已。也就是说，动态函数库的内容并没有被整合到可执行文件当中，而是当可执行 文件要使用到函数库的机制时， 程序才会去读取函数库来使用。由于可执行文件当中仅 具有指向动态函数库所在的指标而已， 并不包含函数库的内容，所以他的文件会比较小 一点。

• 独立执行的状态： 这类型的函数库所编译出来的程序不能被独立执行， 因为当我们使用 到函数库的机制时，程序才会去读取函数库，所以函数库文件“必须要存在”才行，而且， 函数库的“所在目录也不能改变”，因为我们的可可执行文件里面仅有“指标”亦即当要取用 该动态函数库时， 程序会主动去某个路径下读取，呵呵！所以动态函数库可不能随意移 动或删除，会影响很多相依的程序软件喔！

• 升级难易度： 虽然这类型的可执行文件无法独立运行，然而由于是具有指向的功能， 所 以，当函数库升级后，可执行文件根本不需要进行重新编译的行为，因为可执行文件会 直接指向新的函数库文件 （前提是函数库新旧版本的文件名相同喔！）。

目前的 Linux distribution 比较倾向于使用动态函数库，因为如同上面提到的最重要的一点， 就是函数库的升级方便！

绝大多数的函数库都放置在：/lib64, /lib 目录下！ 此外， Linux 系统里面很多的函数库其实 kernel 就提供了，那么 kernel 的函数库放在 /lib/modules

21.5.2 ldconfig 与 /etc/ld.so.conf

略

21.5.3 程序的动态函数库解析： ldd

略

21.6 检验软件正确性

21.6.1 md5sum / sha1sum / sha256sum

目前有多种机制可以计算文件的指纹码，我们选择使用较为广泛的 MD5, SHA1 或 SHA256 加密机制来处理

[root@study ~]# md5sum/sha1sum/sha256sum [-bct] filename
[root@study ~]# md5sum/sha1sum/sha256sum [--status|--warn] --check filename

选项与参数： 
-b ：使用 binary 的读档方式，默认为 Windows/DOS 文件型态的读取方式； 
-c ：检验文件指纹； 
-t ：以文字体态来读取文件指纹。

范例一：将刚刚的文件下载后，测试看看指纹码 
[root@study ~]# md5sum ntp-4.2.8p3.tar.gz

原文地址：http://www.cnblogs.com/huangwenjie/p/16870718.html