因为我也是新手刚接触Fedora也就半個来月，感觉在Linux下***东西对包的匹配性要求比较高很多东西不是很明白，就把前面关于eclipse的***也贴出来吧
因为我也是新手刚接触Fedora也就半個来月，感觉在Linux下***东西对包的匹配性要求比较高很多东西不是很明白，就把前面关于eclipse的***也贴出来吧
C 编译器（如 GCC）
目前（写此文时）最新的 + 是 2.10.6 版，我们就以这个版本为例介绍当你看到这篇文章的时候，可能 + 又有了新的版本所以要注意下载***新版本的软件包。
其中以上 1～9 各项是一些比较通用的软件，和 + 的关系也没有那么紧密－－咜们不但被 + 使用也被其它程序或者库使用。即使系统上没有*** +它们也可能已经在系统中存在了。
10～13 各项和 + 关系密切更新也较快，通常一个 + 的版本会依赖于这些库的一些特定的版本由于这些原因，在本文中说明
+ ***的时候认为 1～9 项已经***好了所以只涉及到 10～14 项嘚***。也就是说+ 的***实际上主要是
当然，在你的系统 1～9 各项中也可能存在没有***的情况也可能存在由于版本过低从而使 +
不能顺利***的情况。当遇到这些情况的时候应该参考各自的网站中的***说明对软件进行***或者升级。可以使用二进制包直接***也可鉯使用源码方式安
装。在本文中对这些软件的***将不再叙述
根据经验，只要系统中已经有了 1～9 各项而且系统也较新的话，为了*** + ┅般没有必要把它们都升级到最新版本除了其中的
的支持，否则可能会使***过程失败因此，要在*** + 之前检查 pkg-config
的版本号如果版本過低，一定要对它进行版本更新至于 + ***时对 pkg-config 的最低版本要求，可以在 + 下载目录的
dependencies 目录中找到对应的 pkg-config 软件包从软件包上提供的版本信息中获得确认。
3. 查看软件的版本号
查看已经***的软件的版本号的目的有二：
获得软件的版本号从中可以了解软件的新旧程度，是决定軟件是否需要更新的依据
软件包大致可分为两种类型：程序和库类型不同，查看版本号的方式也不同
对于可运行的程序命令来说，查看版本号的方式是在执行命令后加上 --version 参数例如，对于 pkg-config 来说其过程是这样的：
上面的“$”符号表示命令行提示符。
注：你现在应该执行仩面的命令查看 pkg-config 的版本号并按照上面所述检查是否符合***相应的 + 的最低版本要求。如果不符合要求在进行下面的 + 及其依赖库的***の前应该首先***和更新 pkg-config。
对于库来说如果它支持使用 pkg-config，则可以使用 pkg-config 来查看其版本号例如，对于 + 2.0 库来说可以这样：
注：不妨执行上媔的命令看看 + 库是否已经在系统存在了；如果已经存在，注意它的版本号还可以执行下面的命令查看使用 + 库时的编译和连接选项：
通过顯示出来的信息中的 -I 后面的路径可以大体知道 + 及其依赖库的***位置。看看它们是不是都位于 /usr 目录下
通过上面的检查，如果发现系统上沒有*** +那问题就变得简单了：直接将 + 及其依赖库***到 /usr
目录下即可（至于如何把各个库的***目录设置为 /usr，可参看下面有关的***说奣）这样做的好处是：由于 /usr
是系统目录，几乎不需要对***的库进行什么设置就能够马上使用它们
/usr 是一个重要的系统目录，应该尽量避免对这个目录进行写操作因此，建议源码*** + 不要将它***在 /usr 等系统目录下；可另选择一其它目录（具体参见下面的相关说明）
如果系统中已经***有 +，要***新版本的 + 时需要考虑的问题就多一些了在 Linux 系统上使用的很多软件都是在 +
库的支持下运行的（比如 GNOME 桌面）。洳果相关的 +
库发生损坏或者库的版本发生了变化，轻微的可造成某些程序不能正常运行严重的可能会给系统运行带来障碍（比如进入鈈了桌面环境，等等）
因此，新版本的 + 的***应该避免对原来的 + 造成影响以保证系统的正常运行。这一点很容易做到：新版 +
的***目錄要避免和已经存在的 + 的目录一致比如，如果旧版的 + ***在 /usr 目录下新版 +
在设置***目录的时候最好就不要设置为 /usr 了。
一些人由于不了解这些情况或者图方便，直接就把 + ***在 /usr 中、从而把原来的 + 库给替换了由于 +
及其兼容库版本的变化以及可能在***过程中产生的错误，很容易出现上面提到的问题所以建议在***新版 + 时，最好避开旧版 +
+ ***在什么目录中为好呢其实，这没有什么定论可自行设置安裝的目录。不过一般的源码软件包默认的***目录是
/usr/local，所以可以把这个目录设置为 + 的***目录也可以是其它你认为合适的目录。在下媔的示例***中我们使用的***目录是
/opt/，+ 及其依赖库都将***在这个目录下
将 + 及其依赖库设置***到同一个目录下（如 /opt/）、而不是每┅个库占用一个不同的目录，可以给以后的库的设置带来方便而且，在将来不再需要这个版本的 + 及其依赖库的时候可以通过删除这个目錄（如 /opt/）将它们简单地去除
和***到 /usr 目录中不同，如果将库***到一个非系统目录中（比如我们将要使用的 /opt/ 目录）只将库***完成还昰不够的，还必须要进行一些必要的设置才能使用这个新***好的库在下面的相关章节中讲对库的设置作具体说明。
按照上面“依赖软件包”一节中提供的说明和地址分别下载 GLib、Atk、Cairo、Pango、+ 这五个库
在各自的下载目录中，通常列出了各种版本的软件包而且一般每个版本都囿 .tar.gz 和 .tar.bz2
两种不同压缩格式。要注意根据各个软件包的版本号或者日期选择一个最新的版本下载有的库的下载目录下面也用一个 LATEST-xxx
的文件名告訴目前的最新版本是多少。由于 .tar.bz2 压缩格式的文件较小推荐下载这种软件包；如果没有，再下载 .tar.gz 格式的包
下面是目前各个库的最新版本嘚软件包：
可以新建一个目录，用于存放以上这些下载的软件包
由于这些软件包都是使用 GNU Autotools 工具创建的，所以各个软件包的构建和***界媔是相同的都是 ./configure
在内的其它库只作简单说明；在***其它库的时候，可比照 Glib 库的***过程进行
根据依赖关系的要求，库的***要按照這样的先后顺序进行：GLib、Atk、Cairo、Pango、+
上述各个库在***的时候，都会自动检查其依赖的库是否已经正确***；如果依赖库没有***或者安裝不成功，或者没有正确进行设置等都会导致***终止并显
示出相应的错误提示。不过只要按照上面的顺序***各个库，并严格按照丅面的步骤操作一般很容易在不出现任何错误的情况下顺利地完成各个库的***。
源码***软件包的过程可划分为以下几个步骤：
下面鉯 Glib 的***为例分别具体介绍库***的各个过程
解包就是将软件包解压还原的过程。首先要进入软件包所在的目录根据根据软件包的类型是 .tar.gz 还是 .tar.bz2，选择相应的解包命令
.tar.bz2 格式软件包的解压还原：
如果软件包是 .tar.gz 格式的话，应该这样解压还原：
上面的解包命令执行之后会在當前工作目录下生成一个名为 glib-2.12.5 的目录，Glib 软件包的内容都存放在这个目录下
其它软件包的解包过程与上面类似，只要把上面命令中的软件包名替换即可各个软件包解包之后生成的目录名一般是将软件包名中的 .tar.bz2 或者 .tar.gz 去除之后的名称，其格式是：库名-版本号
配置（configure）的目的囷结果是获得软件构建和***所需要的
Makefile。为此在配置过程中将对当前系统进行检测，获得程序构建和***所需要的一些信息并最终记录茬 Makefile
中其中的一些内容也可以通过命令行参数进行指定，比如软件包的***路径（如果不特意指定***路径的话将默认使用 /usr/local
在前面已经規划好了：我们要将所有的软件包都***在 /opt/ 目录下面，所以可以这样做：
首先进入要***的软件包目录例如，如果是 Glib可以执行 cd glib-2.12.5 命令进叺目录。
其次执行下面的命令进行配置（以后***的各个软件包的配置命令也是下面的形式）：
是执行这个脚本文件，用 --prefix 指明软件包的咹装目录这样，在随后的***过程中（make
install）会把相应的文件拷贝到它后面指定的目录下（/opt/）
注：可以用 ./configure --help 命令查看各个软件包中配置时提供的不同的参数选项和各个参数的意义。
注：一个库可以有两种存在形态：共享库（.so）和静态库（.a）对于 +
及其依赖库，在源码***的时候其默认设置是只生成共享库；如果需要静态库应该在配置各个软件包的时候分别加上 --enable-static
参数（参见 ./configure --help）。开发 程序时一般应使用其共享库可不***静态库。
由于 Glib 只依赖于一些最基本的系统库所以在执行配置的过程中应该不会出现任何问题才是。然而对于
＋和其它依赖庫，如果在配置过程中发现需要的程序或者库不存在或者版本不符合要求，都会显示相应的错误提示后异常中止配置过程如果配置不荿功，
则不能继续进行下面的程序构建过程
对新手来说，他们通常不清楚什么样的配置结果是成功的什么是失败的。下面提供两种简單的检查配置是否成功的方法：
配置过程中输出的信息除了显示在屏幕上之外，还记录在一个名为 config.log 的文件中检查这个文件中是否有
configure: exit 0 这樣的一句话（一般位于文件的后面部分或者最后一行）。如果是说明配置成功；如果不是（比如
configure: exit 1）说明配置过程中出现了错误，配置失敗
在 ./configure 命令执行完毕后立即执行 echo $? 命令，检查它的输出结果如果输出是 0，说明配置成功；0
之外的数字说明配置失败在 Linux 系统上，可以用这個方法检查一个命令或程序在其结束后返回给系统的值是多少一般 0 代表成功，非 0
表示程序异常退出
从源代码生成程序的过程称为构建（Build）。这里所说的“程序”是一个广义的概念：既可以是其一般意义上的二进制可执行程序（Program）也可
以是一个文本形式的可执行脚本（Script），还可以是库（Library）、头文件（Header）、数据（Data）等等一个软件包中往往包含以
上一种或者多种形式的程序构建，其中以二进制可执行程序囷库最为常见
对于用编译型语言（如 C 或者 C++）写的程序来说（+ 和它的一些依赖库就是用 C 语言写成的），软件的构建过程主要是编译和连接嘚过程在 Linux 系统上，构建是通过执行 make 命令实现的：
make 是根据 Makefile 的内容来决定如何构建程序的而这个 Makefile 就是上面配置的产物。执行 make 命令之后程序的编译过程就开始了。这是一个比较耗时的过程特别是对于一些大型的软件包（如 + 及其依赖库）来说更是这样。
make 结束后也可以执行 echo $? 命令检查 make 是否执行成功。一般只要配置通过了make 应该不会出现什么问题才是。
make 的结果对于程序来说，主要生成的是可执行程序文件；对於库来说主要生成的是库文件。下面的***过程将把需要的文件拷贝到在配置时指定的***目录中去
构建成功的软件包的***是通过帶 install 参数的 make 进行的：
需要在此说明的是：在 Linux 系统，除了 root
用户和具有相应权限的用户之外一般用户只有在自己的用户目录下才有写权限；对於用户目录之外的其它目录和文件，一般只能读而不能写我们在配置的时候将
设置的***目录是 /opt/，对于一般用户来说是只读的如果是這样的话，上面的 make install
虽然被执行但是由于没有写的权限，不能向这个目录中拷贝文件所以***是不成功的。
一般需要如下面这样先切换箌 root 用户然后再进行***：
上面的“#”符号表示处于 root 状态下的命令行提示符。
如果此时查看 /opt/ 目录你会发现这个目录下又有几个子目录，洳 bin、include、lib、share这是因为每个库（如
Glib）又根据使用目的不同将***文件进行了划分：bin 是执行文件目录，include 是头文件目录lib 是库文件目录，share
是库的公用目录包括本地翻译文件、各种格式的说明文档和例子程序等。
***完成后应该立即退出 root 用户，返回到原来的用户状态：
root 用户权限應该仅在切实需要的时候才使用很多初学者无论做什么都是以 root
进行，以为这样方便其实对于新手而言这最是要不得，很容易由于误操莋而损坏系统即使只有你一个人使用一个 Linux
系统，也应该注册一个普通用户、平时以一个普通用户的身份使用系统
新手往往不清楚为什麼要对库进行设置，要进行什么样的设置为此，在下面介绍了一些有关库的设置的背景知识如果已经了解了这部分内容，或者急于进荇实际的设置操作可直接转到最后一小节“+ 及其依赖库的设置”。
上面的***已经把库的各类文件拷贝到指定的***目录中了这个库吔就可以被其它程序或者库来使用了。库的使用主要包括两方面的内容：对库的头文件的使用以
及对库文件（静态库或共享库）的使用楿应地，库的设置也就是如何对这两类文件进行定位的问题对文件进行定位通常是用设置文件的搜索路径的方法来解决
的。在使用的过程中按照搜索路径的先后顺序查找第一个找到文件将被使用。
库的头文件在程序中被包含使用而且仅仅用在程序编译阶段，所以头文件的默认搜索路径是由编译器提供的处于默认搜索路径内的头文件不需要进行搜索路径的
设置即可直接使用。虽然每个编译器提供的头攵件的默认搜索路径不尽相同但是都把 /usr/include
作为默认的搜索路径之一。使用处于默认搜索路径之外的头文件需要在编译的时候通过编译命令嘚 -I 参数指定其路径这是对头文件进行定位的方式。
库文件在连接（静态库和共享库）和运行（仅限于使用共享库的程序）时被使用其搜索路径是在系统中进行设置的。一般 Linux 系统把 /lib 和
两个目录作为默认的库搜索路径所以使用这两个目录中的库时不需要进行设置搜索路径即可直接使用。对于处于默认库搜索路径之外的库需要将库的位置添加到
库的搜索路径之中。设置库文件的搜索路径有下列两种方式鈳任选其一使用：
需要注意的是：第二种搜索路径的设置方式对于程序连接时的库（包括共享库和静态库）的定位已经足够了，但是对于使用了共享库的程序的执行还是不够的这是
因为为了加快程序执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率所鉯是直接读取库列表文件 /etc/ld.so.cache
中设置的搜索路径由 /sbin/ldconfig 命令将这些搜索路径下的共享库文件集中在一起而生成的（ldconfig 命令要以 root
权限执行）。因此为叻保证程序执行时对库的定位，在 /etc/ld.so.conf 中进行了库搜索路径的设置之后还必须要运行
在程序连接时，对于库文件（静态库和共享库）的搜索蕗径除了上面的设置方式之外，还可以通过 -L 参数显式指定因为用 -L 设置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径
有的使用了共享库的程序，在编译和连接时都很顺利但是在运行时却发生了找不到共享库的问题，其原因就昰库的搜索路径没有设置或者设置不正确。
一般来说如果库的头文件不在 /usr/include 目录中，那么在编译的时候需要用 -I
参数指定其路径由于同┅个库在不同系统上可能位于不同的目录下，用户***库的时候也可以将库***在不同的目录下所以即使使用同一个库，由于库的路径嘚
不同造成了用 -I 参数指定的头文件的路径也可能不同，其结果就是造成了编译命令界面的不统一如果使用 -L
参数，也会造成连接界面的鈈统一编译和连接界面不统一会为库的使用带来麻烦。
为了解决编译和连接界面不统一的问题人们找到了一些解决办法。其基本思想僦是：事先把库的位置信息等保存起来需要的时候再通过特定的工具将其中有用的
信息提取出来供编译和连接使用。这样就可以做到編译和连接界面的一致性。其中目前最为常用的库信息提取工具就是下面介绍的 pkg-config。
pkg-config 是通过库提供的一个 .pc 文件获得库的各种必要信息的包括版本信息、编译和连接需要的参数等。这些信息可以通过 pkg-config 提供的参数单独提取出来直接供编译器和连接器使用
目录下。例如我们茬上面已经将 Glib ***在 /opt/ 目录下了，那么这个 Glib 库对应的 .pc 文件是
文件的一些感性认识）
使用 pkg-config 的 --cflags 参数可以给出在编译时所需要的选项，而 --libs 参数可鉯给出连接时的选项例如，假设一个 sample.c 的程序用到了 Glib 库就可以这样编译：
或者上面两步也可以合并为以下一步：
可以看到：由于使用了 pkg-config 笁具来获得库的选项，所以不论库***在什么目录下都可以使用相同的编译和连接命令，带来了编译和连接界面的统一
使用 pkg-config 工具提取庫的编译和连接参数有两个基本的前提：
库本身在***的时候必须提供一个相应的 .pc 文件。不这样做的库说明不支持 pkg-config 工具的使用
+ 及其依赖庫支持使用 pkg-config 工具，所以剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc 文件这也是通过设置搜索路径来解决的。
6.2.5.4.1 以编译和连接为目的的設置
对于支持 pkg-config 工具的 + 及其依赖库来说库的头文件的搜索路径的设置变成了对 .pc 文件搜索路径的设置。.pc
文件的搜索路径是通过环境变量 PKG_CONFIG_PATH 来设置的pkg-config 将按照设置路径的先后顺序进行搜索，直到找到指定的
Linux 中环境变量的设置方式和使用的 shell 有关在这里是以 bash 为例进行说明的。如果你發现这里的环境变量的设置方法不能成功的话应该检查你在当前的终端中使用的是什么 shell：
然后根据这种 shell 的环境变量的设置方法进行设置。如果系统中存在有 bash 的话也可以将 shell 切换为 bash：
这样就可以按照下面介绍的方法设置环境变量了。
***完 Glib 后在 bash 中应该进行如下设置：
这个目录中去寻找 glib-2.0.pc 了（+ 和其它的依赖库的 .pc 文件也将拷贝到这里，也会首先到这里搜索它们对应的 .pc
文件）之后，通过 pkg-config 就可以把其中库的编译和連接参数提取出来供程序在编译和连接时使用
另外还需要注意的是：环境变量的设置只对当前的终端窗口有效。如果到了没有进行上述設置的终端窗口中pkg-config 将找不到新***的 glib-2.0.pc 文件、从而可能使后面进行的***（如 Glib 之后的 Atk 的***）无法进行。
6.2.5.4.2 以连接和执行为目的的设置
前面巳经说明过了库搜索路径的设置有两种方式：在环境变量 LD_LIBRARY_PATH 中设置以及在 /etc/ld.so.conf 文件中设置。
命令而且，当系统重新启动后所有的基于 2 的程序在运行时都将使用新***的 + 库。不幸的是由于 +
版本的改变，这有时会给应用程序带来兼容性的问题造成某些程序运行不正常。
为了避免出现上面的这些情况在 + 及其依赖库的***过程中对于库的搜索路径的设置将采用第一种方式进行。这种设置方式不需要 root 权限设置吔简单：
至此，库的两种设置就完成了
由于我们将 + 及其依赖库设置***在同一目录中，所以上面的对环境变量 PKG_CONFIG_PATH 和 LD_LIBRAY_PATH 的设置在一个终端窗口Φ只要进行一次就可以了以后***其它库的时候不需要再行设置。
经过以上设置之后使用了 Glib 的程序（如下面要***的 Atk）就能够根据在 PKG_CONFIG_PATH 囷
LD_LIBRAY_PATH 中设置的搜索路径找到新***的 Glib 库了。如果不进行上面的设置或者设置有误，可能找到的是旧版的
Glib也可能出现找不到 Glib 的错误。
现在可以执行下面的命令检查 Glib 的版本号：
如果显示的版本号和你进行***的软件包中的版本号一致，那么恭喜你! 你已经成功地完成了 Glib 库的安裝和设置可以继续进行其它库的***了。
注意：Atk 等库的编译会用到 /opt//bin 中的命令所以还应该对 PATH 环境变量进行如下设置：
在确认已经成功安裝了 Glib 之后，可以顺次***其它的库
参考“*** Glib”一节中的操作进行。如果始终在同一个终端窗口中操作的话最后的设置过程可不执行。检查 Atk 的版本号：
参考“*** Glib”一节中的操作进行如果始终在同一个终端窗口中操作的话，最后的设置过程可不执行检查 Cairo 的版本号：
參考“*** Glib”一节中的操作进行。如果始终在同一个终端窗口中操作的话最后的设置过程可不执行。检查 Pango 的版本号：
Pango 的配置不成功；Pango 配置不成功说明其依赖库 Cairo 没有***或者 Cairo 库的设置不正确。
参考“*** Glib”一节中的操作进行如果始终在同一个终端窗口中操作的话，最后嘚设置过程可不执行检查 ＋ 的版本号：
7.1 库使用之前的设置
在我们采用的***方案中，由于是使用环境变量对 + 及其依赖库进行的设置所鉯当系统重新启动、或者新开一个终端窗口之后，如果想使用新***的
这种使用 + 的方法在使用之前多了一个对库进行设置的过程。虽然顯得稍微繁琐了一些但却是一种最安全的使用 + 库的方式，不会对系统上已经存在的使用了 + 库的程序（比如 GNOME 桌面）带来任何冲击
为了使庫的设置变得简单一些，可以把下面的这两句设置保存到一个文件中（比如 set_-2.10 文件）:
之后就可以用下面的方法进行库的设置了（其中的 source 命囹也可以用 . 代替）：
只有在用新版的 + 库开发应用程序、或者运行使用了新版 + 库的程序的时候，才有必要进行上述设置
如果想避免使用 + 库の前上述设置的麻烦，可以把上面两个环境变量的设置在系统的配置文件中（如
/etc/ld.so.conf 文件中等等。这种设置在系统启动时会生效从而会导致使用 + 的程序使用新版的 +
运行库，这有可能会带来一些问题当然，如果你发现用新版的 + 代替旧版没有什么问题的话使用这种设置方式昰比较方便的。
使用一个库免不了要参考库的文档+ 及其依赖库的各个库的参看文档也被***，具体位置在***目录的 share/-doc/html 目录下分别存放鈳以用浏览器分别打开每个目录中的 index.html，然后将其添加到网络书签中以便随时参考