软件是由程序语言写成的。其中，有一类语言称为‘脚本语言’，当您编写完后就可以直接运行，典型代表有 Perl、Python 及 Tcl/Tk。这些语言带有解释器，用来在程序和系统之间做翻译。
另外一类语言，如 C 和 C++， 需将写好的程序先编译成二进制代码（‘binary’），然后才能运行。
自然，每种语言都有各自优缺点：解释型的语言开发起来快；而二进制代码则由于不需要解释器，运行速度更快，也更适合大型的项目。
编译过程是将人们可以阅读的文本，即源代码，翻译成机器可读的文件，也就是二进制代码。所以编译时，您需要的第一件法宝就是编译器。在 Linux 中，‘gcc’用来编译主要由 C 语言写成的程序，而 C++ 是由‘g++’（即‘gcc-c++’）来编译。
一些复杂的程序可能包含大量源代码文件。为了简化编译过程，编译指令经常被放在一个文件中，这就是‘Makefile’文件。要应用这个文件，您就需要 ‘make’程序。‘make’读取（解析‘parse’）‘Makefile’文件，并给编译器提供合适的参数。您可以通过编辑‘Makefile’文件，来改变这些参数（比如将编译好的文件放在何处）。
写程序时，开发员并不需要从零开始，可以用一些库（‘library’），这些库提供了许多常用的函数。开发员只要在源代码文件中，给用到的某些库或库中的函数作适当链接（‘link’），然后，编译好的二进制在运行时就会用到这些库。
现在，如果您编译程序，编译器需要获取程序用到的一些库的源代码文件，这些文件也被称为头文件（‘header file’），所以，您同时也要有这些文件。
由于您只是在编译时才需要头文件，所以有必要将库的RPM包一分为二：一个含有程序运行时需要的文件，而另一个是编译程序时需要的文件。这正是现在发行版的常用办法：一个包是库本身（‘runtime’version）；另外一个，以‘-devel-’（‘development’开发）来标识，里面是头文件。
所以，您同时也需要程序用到的库的头文件包。
您可能会问，如何才能知道程序需要哪些库？最简单的办法是试着编译源代码。如果无法找到需要的库，编译过程将中止。
第二个办法是直接看‘Makefile’文件。在这个文件头部，以 LIBS = 开头的那一行，列出的就是需要的库。请注意，这些库以缩写的方式列出：比如，‘ -lX11’指的是文件名‘libX11.so’。用 locate libX11.so 可以检查这个文件是否已安装在您的系统中。
第三个办法是‘configure’脚本，这个文件由程序员用‘autoconf’工具生成。该脚本运行时，将检查所有需要的库和函数在系统中是否都可用。如果无法满足，将运行失败，并且告诉您出错原因。
常用的库有了这些库，您就可以完成大多数编译，而不会由于缺少某库而出错。
libgtk+-devel, libglib-devel 在部件设定（widget set）中常用
libgr-devel, libungif-devel, libjpeg-devel, libpng-devel, libtiff-devel, libxpm-devel 图像格式
libtermcap-devel, libncurses-devel 用于控制台程序
XFree86-devel 用于所有的图形程序
zlib-devel 有关压缩的库
运行‘configure’
现在，大多数源码包都含有‘configure’脚本，用来检查在当前系统上，能否完成编译。
./configure --help
在源码的目录中，执行上面的命令，将列出一段‘configure’可用参数的摘要。您没必要感到困惑，因为在大多数情况下，默认值就能够顺利通过。
但其中有一个参数，您得留点儿神，这就是‘--prefix=[DIR]’，一般在参数列表的开头。这个参数是用来指定，编译好的程序和库将要安放的位置，一般是‘[/usr]’或‘[/usr/local]’。这两个目录都可以，我个人更喜欢将自编译的程序放在‘/usr/local/’下，这样可以使系统目录结构更加清晰。
但是，有些 KDE 程序以为您有‘/opt/kde’目录，并且将其当成默认安装目录。Mandrake Linux 应该有这么个目录，但由于 KDE 文件都安装在 ‘/usr’下，您可能需要在运行‘configure’时，改变这个值：
./configure --prefix=/usr
您或许不明白，为什么输入‘./configure’而不是‘configure’。这是由于新建的源码目录通常不在您的 shell 路径中，所以，如果您输入 configure，shell 会显示：
bash: configure: command not found
必须告诉 shell，您想执行的命令在当前目录下，这就要在命令前加‘./’。
更多关于 Linux 下的路径设置
请注意：实际不需要、我也不推荐用‘root’帐号运行‘configure’脚本。
<二>缺了什么？
‘configure’开始运行，将检查您的系统。这个过程的输出将在终端上显示，并同时存放到新建的‘config.log’文件中。如果碰到会阻碍完成编译的错误，检查将自动停止。
同时显示出错信息，并写入‘config.log’文件，比如：
/usr/bin/ld: cannot open -lXt: No such file or directory
collect2: ld returned 1 exit status
看起来缺了什么，但‘-lXt’是哪个东东？这是在编程中惯用的表示方法：‘l’表示‘lib...so’，所以需要的是‘libXt.so’文件。
有可能这个文件在您尚未安装的某个 -devel-.rpm 包中。如果您在使用 Mandrake Linux 7 及其后继版本，可以用 ‘Software Manager’（即‘RpmDrake’），来搜索含有这个文件的包（‘Tree - See available packages’然后‘Search - File’），或者在命令行下用 urpmf file。
在旧的发行版本中，可以进入含有 RPM 包的光盘目录中（/mnt/cdrom/Mandrake/RPMS），然后运行命令：
for i in *.rpm ; do rpm -qpli ＄i | grep file && echo ＄i ; done
（用您要搜索的文件名替换 file ）
您将看到，前面缺少的文件属于‘XFree86-devel’包。接下来，就安装这个 RPM 包，可以用您喜欢的 RPM 图形应用程序、‘urpmi’，或使用
su -c 'rpm-i XFree86-devel*'
现在删除源代码目录下的‘config.cache’文件，再运行‘configure’。如此重复，直到‘configure’通过。
如果实在找不到含有您需要文件的 RPM 包（很少见），而且文档中也没有相关的信息， 您可以与软件作者联系，作者应该是再清楚不过了，但是，您务必要先仔细重复前面的步骤。
<三>运行‘make’
如果‘configure’运行成功后，就可以真正地编译源码了：
make
这个过程应当不会出现任何错误，除非‘configure’脚本自身有问题（当然，可能发生意外）。
‘make’时出现的错误可能有些难于理解，但总体来说和前面描述的有些类似。
如果出错，可能如：
file:line: file: No such file or directory
或
file1: in file | function name:
file2:line: undefined reference to function
在第一种情况下，请安装含有相应文件的 RPM 包。有涉及到函数名的错误，经常是由于程序用到的库的版本比已安装的要新或更旧。您可以查一下有没有该库的新版或旧版，然后安装。
通常需要运行：
make clean
再编译试试。
好了，假定您现在已经完成，现在终于可以安装啦！用 root 帐号运行：
su -c 'make install'
准备好了吗？试试新装的程序吧 ;-) 。当然，要确认您已经将可执行文件放到了系统的 路径（path） 中，否则用 ln - s source destination 新建一个符号链接（‘symlink’）到‘/usr/local/bin’，或者也可以将该目录直接添加到系统的路径中。
<四>卸载
许多人都不知道怎么做，但通常卸载用 make install 安装的软件很简单 。您只要到 Makefile 所在的目录，然后键入：
su -c 'make uninstall'
作者在 Makefile 中提供了不少要删去的目标。
如果常常从源代码安装程序，那您得看一下 CheckInstall，这个工具用来将编译好的程序变成 RPM 包，然后直接安装 RPM 包。这样简化了卸载过程（只要用rpm -e name），并且以后安装需要相应文件的 RPM 包时 ，不会出现依赖问题。
Mandrake Linux 8.2 的用户请注意：请不要用您光盘中的 CheckInstall RPM 包，因为其无法工作，您可以从网站上下载 RPM 包。
<五>打补丁
一个补丁或 diff 文件，是特殊格式的文本文件，里面有‘patch’程序要执行的指令，以修改源码文件。
‘patch’命令看起来类似于：
patch -pnumber
容易变化的部分是‘-p’参数后面的‘number’，定义了补丁应用于何种扩展方式的路径：
‘-p0’是应用补丁文件中给出的全路径，‘-p1’则删掉第一个斜杠（slash：/），依此类推。
没有指定的‘-p’将除去全部路径，如果这个补丁只是应用于同一个目录下的文件，这样做就很好。
通常的做法是，将补丁文件放在源代码的上一级目录，然后运行
patch -p1
如果这样不行，试试‘-p’后跟其他数字。
