ld.so.conf 文档和PKG_CONFIG_PATH变量

一、编译和连接
一般来说，假如库的头文档不在 /usr/include目录中，那么在编译的时候需要用-I参数指定其路径。由于同一个库在不同系统上可能位于不同的目录下，用户安装库的时候也能够将库安装在不同的目录下，所以即使使用同一个库，由于库的路径的不同，造成了用-I 参数指定的头文档的路径也可能不同，其结果就是造成了编译命令界面的不统一。假如使用-L参数，也会造成连接界面的不统一。编译和连接界面不统一会为库的使用带来麻烦。

为了解决编译和连接界面不统一的问题，人们找到了一些解决办法。其基本思想就是：事先把库的位置信息等保存起来，需要的时候再通过特定的工具将其中有用的信息提取出来供编译和连接使用。这样，就能够做到编译和连接界面的一致性。其中，现在最为常用的库信息提取工具就是下面介绍的pkg-config。

pkg-config 是通过库提供的一个 .pc文档获得库的各种必要信息的，包括版本信息、编译和连接需要的参数等。这些信息能够通过 pkg-config提供的参数单独提取出来直接供编译器和连接器使用。
The pkgconfig package contains toolsfor passing the include path
and/or library paths to build toolsduring the make file execution.
pkg-config is a function thatreturns meta information for the specified library.
The default setting forPKG_CONFIG_PATH is /usr/lib/pkgconfig
because of the prefix we use toinstall pkgconfig. You may add to
PKG_CONFIG_PATH by exportingadditional paths on your system where
pkgconfig files are installed. Notethat PKG_CONFIG_PATH is only needed
when compiling packages, not duringrun-time.

在默认情况下，每个支持pkg-config 的库对应的 .pc文档在安装后都位于安装目录中的 lib/pkgconfig 目录下。例如，我们在上面已将 Glib安装在 /opt/gtk目录下了，那么这个 Glib 库对应的 .pc 文档是 /opt/gtk/lib/pkgconfig目录下一个叫glib-2.0.pc 的文档：
prefix=/opt/gtk/
exec_prefix=$prefixlibdir=${exec_prefix}/lib
includedir=$prefix/includegli{b}_{g}enmarshal=glib-genmarshalgobjec{t}_{q}uery=gobject-querygli{b}_{m}kenums=glib-mkenumsName:GLibDescription:CUtilityLibraryVersion:2.12.13Libs:-L${libdir} -lglib-2.0
Cflags: -I$includedir/glib-2.0-I${libdir}/glib-2.0/include

使用 pkg-config 的 --cflags参数能够给出在编译时所需要的选项，而 --libs 参数能够给出连接时的选项。例如，假设一个 sample.c 的程式用到了 Glib库，就能够这样编译：
$ gcc -c pkg-config --cflagsglib-2.0 sample.c
然后这样连接：
$ gcc sample.o -o sample pkg-config--libs glib-2.0
或上面两步也能够合并为以下一步：
$ gcc sample.c -o sample pkg-config--cflags --libs glib-2.0
能够看到：由于使用了 pkg-config工具来获得库的选项，所以不论库安装在什么目录下，都能够使用相同的编译和连接命令，带来了编译和连接界面的统一。

使用 pkg-config工具提取库的编译和连接参数有两个基本的前提：
库本身在安装的时候必须提供一个相应的 .pc文档。不这样做的库说明不支持 pkg-config 工具的使用。
pkg-config 必须知道要到哪里去寻找此 .pc文档。
GTK+ 及其依赖库支持使用 pkg-config工具，所以剩下的问题就是如何告诉 pkg-config 到哪里去寻找库对应的 .pc文档，这也是通过配置搜索路径来解决的。

对于支持 pkg-config 工具的 GTK+及其依赖库来说，库的头文档的搜索路径的配置变成了对 .pc 文档搜索路径的配置。.pc文档的搜索路径是通过环境变量PKG_CONFIG_PATH 来配置的，pkg-config 将按照配置路径的先后顺序进行搜索，直到找到指定的.pc文档为止。

安装完 Glib 后，在 bash 中应该进行如下配置：
$ exportPKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
能够执行下面的命令检查是否 /opt/gtk/lib/pkgconfig路径已配置在 PKG_CONFIG_PATH 环境变量中：
$ echo $PK{G}_{C}ONFI{G}_{P}ATH这样配置之后，使用Glib库的其他程式或库在编译的时候pkg-config就知道首先要到/opt/gtk/lib/pkgconfig这个目录中去寻找glib-2.0.pc了（GTK+和其他的依赖库的.pc文档也将拷贝到这里，也会首先到这里搜索他们对应的.pc文档）。之后，通过pkg-config就能够把其中库的编译和连接参数提取出来供程式在编译和连接时使用。另外还需要注意的是：环境变量的配置只对当前的终端窗口有效。假如到了没有进行上述配置的终端窗口中，pkg-config将很难找到新安装的glib-2.0.pc文档、从而可能使后面进行的安装（如Glib之后的Atk的安装）无法进行。在我们采用的安装方案中，由于是使用环境变量对GTK+及其依赖库进行的配置，所以当系统重新启动、或新开一个终端窗口之后，假如想使用新安装的GTK+库，需要如上面那样重新配置PK{G}_{C}ONFI{G}_{P}ATH和L{D}_{L}IBRAR{Y}_{P}ATH环境变量。这种使用GTK+的方法，在使用之前多了一个对库进行配置的过程。虽然显得稍微繁琐了一些，但却是一种最安全的使用GTK+库的方式，不会对系统上已存在的使用了GTK+库的程式（比如GNOME桌面）带来任何冲击。为了使库的配置变得简单一些，能够把下面的这两句配置保存到一个文档中（比如se{t}_{g}tk-2.10文档）:exportPK{G}_{C}ONFI{G}_{P}ATH=/opt/gtk/lib/pkgconfig:$PKG_CONFIG_PATH
exportLD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
之后，就能够用下面的方法进行库的配置了（其中的 source命令也能够用 . 代替）：
$ source set_gtk-2.10
只有在用新版的 GTK+ 库研发应用程式、或运行使用了新版 GTK+库的程式的时候，才有必要进行上述配置。
假如想避免使用 GTK+库之前上述配置的麻烦，能够把上面两个环境变量的配置在系统的配置文档中（如
/etc/profile）或自己的用户配置文档中（如~/.bash_profile） ；库的搜索路径也能够配置在
/etc/ld.so.conf文档中，等等。这种配置在系统启动时会生效，从而会导致使用 GTK+ 的程式使用新版的 GTK+
运行库，这有可能会带来一些问题。当然，假如您发现用新版的GTK+
代替旧版没有什么问题的话，使用这种配置方式是比较方便的。加入到~/.bashrc中，例如：
PKG_CONFIG_PATH=/opt/gtk/lib/pkgconfig
重启之后：
[root@localhost ~]# echo$PKG_CONFIG_PATH
/opt/gtk/lib/pkgconfig
二、运行时
库文档在连接（静态库和共享库）和运行（仅限于使用共享库的程式）时被使用，其搜索路径是在系统中进行配置的。一般 Linux
系统把 /lib 和 /usr/lib
两个目录作为默认的库搜索路径，所以使用这两个目录中的库时无需进行配置搜索路径即可直接使用。对于处于默认库搜索路径之外的库，需要将库的位置添加到
库的搜索路径之中。配置库文档的搜索路径有下列两种方式，可任选其一使用：
在环境变量 LD_LIBRARY_PATH中指明库的搜索路径。
在 /etc/ld.so.conf 文档中添加库的搜索路径。 将自己可能存放库文档的路径都加入到/etc/ld.so.conf中是明智的选择 ^_
添加方法也极其简单，将库文档的绝对路径直接写进去就OK了，一行一个。例如：
/usr/X11R6/lib
/usr/local/lib
/opt/lib

需要注意的是：第二种搜索路径的配置方式对于程式连接时的库（包括共享库和静态库）的定位已足够了，但是对于使用了共享库的程式的执行还是不够的。这是因为为了加快程式执行时对共享库的定位速度，避免使用搜索路径查找共享库的低效率，所以是直接读取库列表文档/etc/ld.so.cache从中进行搜索的。/etc/ld.so.cache 是个非文本的数据文档，不能直接编辑，他是根据/etc/ld.so.conf中配置的搜索路径由 /sbin/ldconfig命令将这些搜索路径下的共享库文档集中在一起而生成的（ldconfig 命令要以root权限执行）。因此，为了确保程式执行时对库的定位，在 /etc/ld.so.conf中进行了库搜索路径的配置之后，还必须要运行/sbin/ldconfig 命令更新 /etc/ld.so.cache文档之后才能够。ldconfig,简单的说，他的作用就是将/etc/ld.so.conf列出的路径下的库文档缓存到/etc/ld.so.cache以供使用。因此当安装完一些库文档，(例如刚安装好glib)，或修改ld.so.conf增加新的库路径后，需要运行一下/sbin/ldconfig使任何的库文档都被缓存到ld.so.cache中，假如没做，即使库文档明明就在/usr/lib下的，也是不会被使用的，结果编译过程中抱错，缺少xxx库，去查看发现明明就在那放着，搞的想大骂computer蠢猪一个。^_
在程式连接时，对于库文档（静态库和共享库）的搜索路径，除了上面的配置方式之外，还能够通过 -L 参数显式指定。因为用 -L配置的路径将被优先搜索，所以在连接的时候通常都会以这种方式直接指定要连接的库的路径。
前面已说明过了，库搜索路径的配置有两种方式：在环境变量LD_LIBRARY_PATH 中配置连同在/etc/ld.so.conf 文档中配置。其中，第二种配置方式需要 root权限，以改变 /etc/ld.so.conf 文档并执行/sbin/ldconfig 命令。而且，当系统重新启动后，任何的基于GTK2 的程式在运行时都将使用新安装的 GTK+ 库。不幸的是，由于GTK+版本的改变，这有时会给应用程式带来兼容性的问题，造成某些程式运行不正常。为了避免出现上面的这些情况，在GTK+及其依赖库的安装过程中对于库的搜索路径的配置将采用第一种方式进行。这种配置方式无需 root 权限，配置也简单：
$ exportLD_LIBRARY_PATH=/opt/gtk/lib:$LD_LIBRARY_PATH
能够用下面的命令查看 LD_LIBRAY_PATH的配置内容：
$ echo $LD_LIBRARY_PATH
至此，库的两种配置就完成了